всем привет,

# Слайд 1 - Вступление
меня зовут Денис, я тех лид команды T05. Я расскажу о том, как используя данный подход, облегчить жизнь разработчиков, и избавить их от рутины - написания bioler plate кода.

Сегодня мы рассмотрим наиболее популярные технологии, используемые в ecom tech.
Такие как:
* реализация rest api
* реализация gql
* реализация event streaming

# След. слайд
Начнём с наиболее популярного - это реализация REST API.

# Слайд 2 - Реализация REST API
Рассматривать будем на примере реализации метода поиска сырков.

Disclaimer: далее будут слайды с кодом, код вымешлен, не используйте такой код в проде.

Что требуется сделать разработчку в классическом подходе:
* реализовать DTO для REQ\RESP, описанный аналитиком в confluence
* реализовать интерфейс контроллера и клиента

# Cлед слайд
* помимо этого, необходимо добавить spring аннотации: request mapping, validation и т.д.
# след слайд
* так же, хороший разработчик, добавит swagger аннотации содержащие мета-информацию, описывающие end point.
* и наконец, реализовать бизнес-логику метода.

Проблемы:
* при ручном переносе контрактов из confluence в код, есть вероятность допустить ошибки;
* названия полей и типов в аналитике и разработке могут отличаться, что в свою очеред ухудшает чтение документации;
* при изменении в confluence, необходимо не забыть внести правки в коде. Т.е., при изм-я одного контракта в аналитике, необходимо внести правки в двух местах; А если есть ещё и FE, то в трёх!

# Слайд 3 - Реализация REST API
решение:
* возвращаясь к рассказу Игоря, мы помним, что аналитики постарались, и описали контракты в виде OpenApi спецификаций.
* в процессе сборки проекта, по этим спецификация, были сгенерированы и опубликованы артефакты, в виде jar, с котрактами - это DTO, интрейфейсы контроллеров и клиентов

# Слайд 4 - Реализация REST API
* теперь, все что остаётся сделать разработчику, это подключить артфакт, как зависимость

# След слайд
* и реализовать бизнес логику методов
* на данном слайде можно видеть, на сколько локаничнее стал код, в нём нет ничего лишнего, вся мета-информация скрыта в сгенерированном интерфейсе

# След слайд
* вот так он выглядит
* c REST мы разобрались, давайте перейдём дальше и рассмотрим след технологию - GQL

# Слайд 6 - Реализация GQL
в общем и целом, использование данного подхода, для реализации GQL, очень похожи, за тем исключением, что генерация: типов и клиентов происходит на стороне самого сервиса.

# Слайд 7 - Подключаем GQL схему в сервисе
Рассмотрим пример:
* разработчик, как и в предыдущем примере, подключает GQL схему чз зависимости
* тем самым мы получаем graqhql схемы из аналитики

# Слайд 8 - Настройка GQL генератора
* далее, необходимо настроить генератор и передать ему на вход схемы, подключЁнные на предыдущем шаге
* по данным схемам будут сгенерированы DTO и клиенты
* следователно, как и в подходе с REST, разработчику остаётся лишь реализовать БЛ метода

# след слайд
далее рассмотрим ES

# Слайд 9 - Реалзация ES
Проблемы:
1. для реализации ES требуется JSON Schema, которая должна быть расположена в папке с ресурсами сервиса, данная схема используется для проверки сообщения, отправляемого в kafka topic; следовательно разработчику нужно найти схему из confluence, и перенести её в ресурсы сервиса и реализовать DTO, который соответсвует схеме;
2. т.к. всё в confluence хранится как plain text, то отсутствует какой-либо статический анализ содержимого;
3. внесение изм-й в схему усложнено тем, что в confluence отсутсвует редактор JSON схем, поэтому приходится сначала копировать схему из confluence во внешний редактор, вносить изм-я, а затем переносить обратно в confluence.
4. При переходе на apucurio, требуется создать МР с новой схемой в проекте reestr-schemas

# След слайд
Как же мы решили все эти проблемы:
* SA ведут JSON схемы в проекте с аналитикой;
* благодаря этому, средствами IDE производится статический анализ схемы;
* по JSON схеме во время сборки проекта генерируется исходный код контрактов, компилируется и упаковывается в JAR вместе со схемой. Далее, полученные JAR-файлы публикуются в nexus;
* после того, как схема попадает в master-ветку, автоматически создаётся новый МР в проекте reestr-schema, и в неё добавляется файл с изменённой схемой;

# след слайд
И снова всё что нужно сделать разработчику, это подключить схему в зависимости и реализовать бизнес логику.

# Слайд 10 - Итоги
* разработчики ленивые, мы не хотим писать bioler plate код - мы хотим писать бизнес-логику;
* используйте генераторы - они позволяют избежать ошибки людей и избавить от рутины;
* так же, стоит отметить, данный подход не ограничивается генерацией кода для kotlin или java, вы можете использовать генераторы для других языков: Ruby, Go, и другие.
* На front-end мы так же используем генераторы кода по спецификациям, полученным с BE, тем самым, гарантируя доступность запрашиваемых методов и полей сущностей;

Ну, и вишенка на торте:
* в связке с MapStruct в режиме `unmappedTargetType = Error`, что означает, все target поля должны иметь source value. Мы получаем проверку маппинга всех полей (возвращаемых\принимаемых) на уровне компиляции кода;

# След слайд
на данном слайде, вы можете можете видеть, какие технологии мы используем для реализации даного подхода.
Плагины мы реализовали на Kotlin, но так же, есть возможность использовать: java, groovy, scala и др. языки программирования. Например: для генерации интерактивной документации GQL, мы используем nodejs.

Большое спасибо, готовы ответить на ваши вопросы.

Все полезные ссылки на наш проект и статический сайт мы оставим в презентации. Доступ к презентации будет после митапа.всем привет,

# Слайд 1 - Вступление
меня зовут Денис, я тех лид команды. Я расскажу о том, как используя данный подход, облегчить жизнь разработчиков, и избавить их от рутины - написания bioler plate кода.

Сегодня мы рассмотрим наиболее популярные технологии, используемые в ecom tech.
Такие как:
* реализация rest api
* реализация gql
* реализация event streaming

# След. слайд
Начнём с наиболее популярного - это реализация REST API.

# Слайд 2 - Реализация REST API
Рассматривать будем на примере реализации метода поиска сырков.

Disclaimer: далее будут слайды с кодом, код вымешлен, не используйте такой код в проде.

Что требуется сделать разработчку в классическом подходе:
* реализовать DTO для REQ\RESP, описанный аналитиком в confluence
* реализовать интерфейс контроллера и клиента

# Cлед слайд
* помимо этого, необходимо добавить spring аннотации: request mapping, validation и т.д.
# след слайд
* так же, хороший разработчик, добавит swagger аннотации содержащие мета-информацию, описывающие end point.
* и наконец, реализовать бизнес-логику метода.

Проблемы:
* при ручном переносе контрактов из confluence в код, есть вероятность допустить ошибки;
* названия полей и типов в аналитике и разработке могут отличаться, что в свою очеред ухудшает чтение документации;
* при изменении в confluence, необходимо не забыть внести правки в коде. Т.е., при изм-я одного контракта в аналитике, необходимо внести правки в двух местах; А если есть ещё и FE, то в трёх!

# Слайд 3 - Реализация REST API
* возвращаясь к рассказу Игоря, мы помним, что аналитики постарались, и описали контракты в виде OpenApi спецификаций.
* в процессе сборки проекта, по этим спецификация, были сгенерированы и опубликованы артефакты, в виде jar, с котрактами - это DTO, интрейфейсы контроллеров и клиентов

# Слайд 4 - Реализация REST API
* теперь, все что остаётся сделать разработчику, это подключить артфакт, как зависимость gradle

# След слайд
* и реализовать бизнес логику методов
* на данном слайде можно видеть, на сколько локаничнее стал код, в нём нет ничего лишнего, вся мета-информация скрыта в сгенерированном интерфейсе

# След слайд
* вот так он выглядит
* c REST мы разобрались, давайте перейдём дальше и рассмотрим след технологию - GQL

# Слайд 6 - Реализация GQL
в общем и целом, использование данного подхода, для реализации GQL, очень похожи, за тем исключением, что генерация: типов и клиентов происходит на стороне самого сервиса.

# Слайд 7 - Подключаем GQL схему в сервисе
Рассмотрим пример:
* разработчик, как и в предыдущем примере, подключает GQL схему чз зависимости в gradle
* тем самым мы получаем graqhql схемы из аналитики

# Слайд 8 - Настройка GQL генератора
* далее, необходимо настроить генератор и передать ему на вход схемы, подключённые на предыдущем шаге
* по данным схемам будут сгенерированы DTO и клиенты
* поэтому, как и в подходе с REST, разработчику остаётся лишь реализации БЛ метода

далее рассмотрим ES

# Слайд 9 - Реалзация ES
Проблемы:
1. для реализации ES требуется JSON Schema, которая должна быть расположена в папке с ресурсами сервиса, данная схема используется для проверки сообщения, отправляемого в kafka topic; следовательно разработчику нужно найти схему из confluence, и перенести её в ресурсы сервиса и реализовать DTO, который соответсвует схеме;
2. т.к. всё в confluence хранится как plain text, то отсутствует какой-либо статический анализ содержимого;
3. внесение изм-й в схему усложнено тем, что в confluence отсутсвует редактор JSON схем, поэтому приходится сначала копировать схему из confluence во внешний редактор, вносить изм-я, а затем переносить обратно в confluence.
4. При переходе на apucurio, требуется создать МР с новой схемой в проекте reestr-schemas
Подробно об этом см. [тут](https://space.samokat.ru/pages/viewpage.action?pageId=4026192283)

# След слайд
Как же мы решили все эти проблемы:
* как ранее упоминалось, в части Игоря, SA ведут JSON схемы в проекте с аналитикой;
* благодаря этому, средствами IDE производится статический анализ схемы;
* по JSON схеме во время сборки проекта генерируется исходный код контрактов, компилируется и упаковывается в JAR вместе со схемой;
* далее, полученные JAR-файлы публикуются в nexus;
* после того, как схема попадает в master-ветку, автоматически создаётся новый МР в проекте reestr-schema, и в неё добавляется файл с изменённой схемой;

# след слайд
И снова всё что нужно сделать разработчику, это подключить схему в зависимости и реализовать бизнес логику.

# Слайд 10 - Итоги
* разработчики ленивые, мы не хотим писать bioler plate код - мы хотим писать бизнес-логику;
* используйте генераторы - они позволяют избежать ошибки людей и избавить от рутины;
* так же, стоит отметить, данный подход не ограничивается генерацией кода для kotlin или java, вы можете использовать генераторы для других языков: Ruby, Go, и другие.
* На front-end мы так же используем генераторы кода по спецификациям, полученным с BE, тем самым, гарантируя доступность запрашиваемых методов и полей сущностей;

Ну, и вишенка на торте:
* в связке с MapStruct в режиме `unmappedTargetType = Error`, что означает, все target поля должны иметь source value. Мы получаем проверку маппинга всех полей (возвращаемых\принимаемых) на уровне компиляции кода;

# След слайд
на данном слайде, вы можете можете видеть, какие технологии мы используем для реализации даного подхода.
Плагины мы реализовали на Kotlin, но так же, есть возможность использовать: java, groovy, scala и др. языки программирования. Например: для генерации интерактивной документации GQL, мы используем nodejs.

Большое спасибо, готовы ответить на ваши вопросы.

Все полезные ссылки на наш проект и статический сайт мы оставим в презентации. Доступ к презентации будет после митапа.