Организатор
Организую Складчины
Команда форума
- Сообщения
- 603 090
- Реакции
- 12 985
- Монеты
- 325
- Оплачено
- 1
- Ссылка на картинку
Пишем сервис на Go
От А до Я разберём написание сервисов в Go на примере чата поддержки банка
Глобальная задача курса:
Написать с нуля бекенд для чата поддержки банка со всеми вытекающими. После прохождения курса не должно остаться непонятных моментов в том, как могут быть разработаны и устроены сервисы на Go.
Начнем с обсуждения архитектуры, организации пакетов, директорий и инструментов, необходимых для локальной разработки. Спроектируем и реализуем клиентское и менеджерское API, поиграемся с фреймворками и кодогенерацией. Подключим аутентификацию, хранилище и очереди. Не забудем про логирование, конфигурирование и развертывание. И, конечно же, тесты!
Курс разделён на две части – 7 основных недель, посвящённых непосредственно сервису, и 2 доп. недели, посвящённых его горизонтальному масштабированию, деплою и мониторингу.
Вы получаете
01 Неделя первая. Вводная
На этой неделе мы должны понять правила игры, научиться проходить уроки, выполнять задачи и сдавать рубежные контроли. Также мы с высоты птичьего полёта посмотрим на архитектуру (bird's eye view) и осознаем, что же нам предстоит сделать за курс.
К концу недели у вас должен быть настроен Git-репозиторий, содержащий скелет проекта и необходимые для грамотной разработки мелочи вроде линтеров, запускатора локальных задач, логирования, конфигурации и debug-сервера.
02 Неделя вторая. Становится интереснее
На этой неделе начнем с запуска зависимостей с помощью docker-compose. Первое на очереди – хранилище PostgreSQL. Чтобы два раза не вставать, сразу прикрутим Sentry.
Передохнем от докеров и поиграемся с кодогенерацией – нам понадобятся идентификаторы сущностей. Будем генерировать их типы. Чтобы идентификаторы не повисли до лучших времен, сразу их заиспользуем: обратно сгенерируем гошную обвязку над хранилищем, предварительно по косточкам разобрав схему данных.
Добавим ещё одну зависимость, которая решит за нас задачу аутентификации и авторизации – Keycloak. Заведём новый контейнер в docker-compose, познакомимся с фронтенд частью сервиса (не пугайтесь, она будет готовой), добавим пользователей в Keycloak и напишем HTTP-клиент к нему.
Вишенка на торте этой недели – обмазаться Swagger-ом. Напишем спецификацию клиентского API, сгенерируем обвязку, навесим миддлварей.
К концу недели у вас должна быть СУБД и код по работе с ней, решена задача аутентификации и авторизации, каркас клиентского API.
03 Неделя третья. Архитектура
Новая неделя – новые вызовы.
Начнем с обзора архитектурных принципов, на которые будем ориентироваться при разработке сервиса. TL;DR: мы будем стараться делать всё хорошо. Слоистая архитектура, правильное выстраивание направления зависимостей – наше всё.
Сменим теорию практикой. Будем от и до делать первый usecase – получение истории сообщений в чате клиента банка. Запилим слой репозитория. Запилим юзкейс, который будет этим репозиторием пользоваться. И всё? Нет, ещё добавим мяса в хендлер, который сгенерировали на прошлой неделе. Готовый юзкейс протестируем – запустим UI и посмотрим, как получаем сообщения.
Закрепим усвоенное в предыдущем уроке – сделаем ещё один хендлер, но теперь по отправке сообщения в чат. Перед тем, как бросаться в бой, всё же почитаем немного теории про идемпотентность. Пощупаем E2E-тесты. И, как водится, глядя в заготовку, реализуем отправку сообщения.
В конце недели у нас должны быть два работающих API-метода.
А ещё соберемся на вебинаре и ответим на накопившиеся вопросы.
04 Неделя четвёртая. Сложные приколы
Новая неделя, неделя кодинга.
Outbox. Мы делаем всё надежно, атомарно, поэтому без реализации этого широко известного в узких кругах паттерна не обойтись. На входе, как обычно, теория, тесты и верхнеуровневое API компонента.
Outbox-у нужен кто-то, кто будет отправлять события в шину данных (спойлер – это будет Kafka). Будем этого кого-то называть продюсером. Задача продюсера инкапсулировать в себе логику по шифрованию сообщения и взаимодействию с Kafka. По традиции – теория, заготовка с тестами. Чтобы вас не мучать при написании интеграционных тестов, конфигурацию Kafka в docker-compose даём сразу
Идёт четвертая неделя, а менеджеры, которые помогают клиентам решать проблемы, сидят неохваченными. Охват начнем с написания компонентов "пул менеджеров" и сервиса их загруженности. Первый компонент – выдает незанятых менеджеров, готовых помочь своим клиентам (т.е. заставляет работать). Второй компонент следит за тем, чтобы менеджер не слишком много работал (мы ведь просвещенные капиталисты и заботимся о всех, не так ли?).
В заключительном уроке недели обратим внимание на API менеджера. Поднимем отдельный сервер, подключим менеджерский UI, заведём пару новых методов API по уже отработанным методикам.
В конце недели продолжается складываться паззл. Добавится парочка хитрых сервисов, начнется работа над менеджерским API.
05 Неделя пятая. РАБотаем!
Добро пожаловать в новую неделю. На ней продолжим кодить интересные штуки.
Начнем с WebSocket-ов. Чат-сервис требует красоты, сообщения должны появляться в real-time, без перезагрузки страницы. Первым делом сформулируем идеологию их применения. Затем почитаем теоретические выжимки, чтобы точно понимать происходящее, и, наконец, приступим к делу – реализуем пакет, инкапсулирующий в себе работу с вебсокетами. Он будет апгрейдить соединение до вебсокетного, поддерживать его пингами-понгами, читать события из некоего "потока" (реализуем чуть погодя), писать их в WS-соединение.
Продолжим собирать кусочки паззла – реализуем тот самый "поток" событий. Спойлер: в конце урока мы сможем увидеть, как отправленное событие в одной вкладке, появится в другой вкладке Публичный API компонента "потока" мы уже знаем. Будут тесты, осталось сделать так, чтобы они проходили. Заведем события в openapi-схему, покодогенерируем, сделаем адаптер и начнем их писать в "поток".
AFC. На входе будет Docker-образ специально обученного искать "опасные" сообщения контейнера. Его мы и называем AFC-эмулятор. Эмулятор либо блокирует, либо разрешает публикацию сообщения пользователя. Наша задача – обрабатывать "вердикты" эмулятора. Готовьтесь к написанию Kafka-консумера
В конце недели у нас с вами будет готовый скелет вебсокетов, который останется только обогатить новыми типами событий. Поток событий также будет реализован. Будет поддержана AFC-обработка сообщений.
06 Неделя шестая. Добиваем менеджерский флоу
Новая неделя. Чутка передохнем, нагрузки будет поменьше!
Реализуем компонент, распределяющий проблемы пользователей (как звучит-то) на менеджеров. О том, что менеджер назначен на какую-то проблему нужно уведомлять не только менеджера, но и пользователя (не зря мы заводили всякие потоки и вебсокеты на прошлой неделе). Но штука не в этом. Здесь не будет привычных тестов, на которые можно опираться. Надо будет написать всё самим, опираясь на словесное описание. Прямо как в реальной жизни
На втором уроке реализуем историю сообщений для менеджера, почти по аналогии с клиентом. Ограничения на видимость будут только слегка другие. Ещё напомним, что у менеджера есть ещё и сам список чатов, чтобы решать проблемы разных пользователей. Надо будет сделать ещё и это. После того, как вы это сделаете, посмотрите, как легко заезжают новые ручки
Вишенка на торте – урок так и называется. Научим менеджера отправлять сообщения. По стандарту заведем: ручку, юзкейс, пару методов в репозитории, outbox-задачу. После реализации можно будет залогиниться клиентом и менеджером, и попробовать попереписываться.
В конце всё должно работать. Здесь мы с вами дошли до MVP, который уже не стыдно показать миру.
07 Неделя седьмая, финальная. Свободное плаванье
На последней седьмой неделе вам будет предоставлена возможность самостоятельно реализовать новые фичи с использованием любых технологий и инструментов, которых требует ваша душа.
08 [IN DEV] Неделя восьмая, дополнительная. Готовимся к проду
Предварительно:
1 Введение
2 Внедрение трейсинга
3 Внедрение мониторинга
4 Подготовка к масштабированию
5 Рубежный контроль
09 [IN DEV] Неделя девятая, дополнительная. Инфраструктура
Предварительно:
1 Введение
2 Знакомство с Kubernetes
3 Развёртывание сервиса в minikube
4 Рубежный контроль
5 Заключение по второй части курса
От А до Я разберём написание сервисов в Go на примере чата поддержки банка
Глобальная задача курса:
Написать с нуля бекенд для чата поддержки банка со всеми вытекающими. После прохождения курса не должно остаться непонятных моментов в том, как могут быть разработаны и устроены сервисы на Go.
Начнем с обсуждения архитектуры, организации пакетов, директорий и инструментов, необходимых для локальной разработки. Спроектируем и реализуем клиентское и менеджерское API, поиграемся с фреймворками и кодогенерацией. Подключим аутентификацию, хранилище и очереди. Не забудем про логирование, конфигурирование и развертывание. И, конечно же, тесты!
Курс разделён на две части – 7 основных недель, посвящённых непосредственно сервису, и 2 доп. недели, посвящённых его горизонтальному масштабированию, деплою и мониторингу.
Вы получаете
- Доступ к продвинутой теории по теме курса и спискам литературы
- Разработанный вами полноценный сервис, который можно приложить в резюме
- Ревью процесса разработки сервиса преподавателями
- Чат с поддержкой группы на время обучения
- Вебинары с вопросами и ответами в течении курса
01 Неделя первая. Вводная
На этой неделе мы должны понять правила игры, научиться проходить уроки, выполнять задачи и сдавать рубежные контроли. Также мы с высоты птичьего полёта посмотрим на архитектуру (bird's eye view) и осознаем, что же нам предстоит сделать за курс.
К концу недели у вас должен быть настроен Git-репозиторий, содержащий скелет проекта и необходимые для грамотной разработки мелочи вроде линтеров, запускатора локальных задач, логирования, конфигурации и debug-сервера.
02 Неделя вторая. Становится интереснее
На этой неделе начнем с запуска зависимостей с помощью docker-compose. Первое на очереди – хранилище PostgreSQL. Чтобы два раза не вставать, сразу прикрутим Sentry.
Передохнем от докеров и поиграемся с кодогенерацией – нам понадобятся идентификаторы сущностей. Будем генерировать их типы. Чтобы идентификаторы не повисли до лучших времен, сразу их заиспользуем: обратно сгенерируем гошную обвязку над хранилищем, предварительно по косточкам разобрав схему данных.
Добавим ещё одну зависимость, которая решит за нас задачу аутентификации и авторизации – Keycloak. Заведём новый контейнер в docker-compose, познакомимся с фронтенд частью сервиса (не пугайтесь, она будет готовой), добавим пользователей в Keycloak и напишем HTTP-клиент к нему.
Вишенка на торте этой недели – обмазаться Swagger-ом. Напишем спецификацию клиентского API, сгенерируем обвязку, навесим миддлварей.
К концу недели у вас должна быть СУБД и код по работе с ней, решена задача аутентификации и авторизации, каркас клиентского API.
03 Неделя третья. Архитектура
Новая неделя – новые вызовы.
Начнем с обзора архитектурных принципов, на которые будем ориентироваться при разработке сервиса. TL;DR: мы будем стараться делать всё хорошо. Слоистая архитектура, правильное выстраивание направления зависимостей – наше всё.
Сменим теорию практикой. Будем от и до делать первый usecase – получение истории сообщений в чате клиента банка. Запилим слой репозитория. Запилим юзкейс, который будет этим репозиторием пользоваться. И всё? Нет, ещё добавим мяса в хендлер, который сгенерировали на прошлой неделе. Готовый юзкейс протестируем – запустим UI и посмотрим, как получаем сообщения.
Закрепим усвоенное в предыдущем уроке – сделаем ещё один хендлер, но теперь по отправке сообщения в чат. Перед тем, как бросаться в бой, всё же почитаем немного теории про идемпотентность. Пощупаем E2E-тесты. И, как водится, глядя в заготовку, реализуем отправку сообщения.
В конце недели у нас должны быть два работающих API-метода.
А ещё соберемся на вебинаре и ответим на накопившиеся вопросы.
04 Неделя четвёртая. Сложные приколы
Новая неделя, неделя кодинга.
Outbox. Мы делаем всё надежно, атомарно, поэтому без реализации этого широко известного в узких кругах паттерна не обойтись. На входе, как обычно, теория, тесты и верхнеуровневое API компонента.
Outbox-у нужен кто-то, кто будет отправлять события в шину данных (спойлер – это будет Kafka). Будем этого кого-то называть продюсером. Задача продюсера инкапсулировать в себе логику по шифрованию сообщения и взаимодействию с Kafka. По традиции – теория, заготовка с тестами. Чтобы вас не мучать при написании интеграционных тестов, конфигурацию Kafka в docker-compose даём сразу
Идёт четвертая неделя, а менеджеры, которые помогают клиентам решать проблемы, сидят неохваченными. Охват начнем с написания компонентов "пул менеджеров" и сервиса их загруженности. Первый компонент – выдает незанятых менеджеров, готовых помочь своим клиентам (т.е. заставляет работать). Второй компонент следит за тем, чтобы менеджер не слишком много работал (мы ведь просвещенные капиталисты и заботимся о всех, не так ли?).
В заключительном уроке недели обратим внимание на API менеджера. Поднимем отдельный сервер, подключим менеджерский UI, заведём пару новых методов API по уже отработанным методикам.
В конце недели продолжается складываться паззл. Добавится парочка хитрых сервисов, начнется работа над менеджерским API.
05 Неделя пятая. РАБотаем!
Добро пожаловать в новую неделю. На ней продолжим кодить интересные штуки.
Начнем с WebSocket-ов. Чат-сервис требует красоты, сообщения должны появляться в real-time, без перезагрузки страницы. Первым делом сформулируем идеологию их применения. Затем почитаем теоретические выжимки, чтобы точно понимать происходящее, и, наконец, приступим к делу – реализуем пакет, инкапсулирующий в себе работу с вебсокетами. Он будет апгрейдить соединение до вебсокетного, поддерживать его пингами-понгами, читать события из некоего "потока" (реализуем чуть погодя), писать их в WS-соединение.
Продолжим собирать кусочки паззла – реализуем тот самый "поток" событий. Спойлер: в конце урока мы сможем увидеть, как отправленное событие в одной вкладке, появится в другой вкладке Публичный API компонента "потока" мы уже знаем. Будут тесты, осталось сделать так, чтобы они проходили. Заведем события в openapi-схему, покодогенерируем, сделаем адаптер и начнем их писать в "поток".
AFC. На входе будет Docker-образ специально обученного искать "опасные" сообщения контейнера. Его мы и называем AFC-эмулятор. Эмулятор либо блокирует, либо разрешает публикацию сообщения пользователя. Наша задача – обрабатывать "вердикты" эмулятора. Готовьтесь к написанию Kafka-консумера
В конце недели у нас с вами будет готовый скелет вебсокетов, который останется только обогатить новыми типами событий. Поток событий также будет реализован. Будет поддержана AFC-обработка сообщений.
06 Неделя шестая. Добиваем менеджерский флоу
Новая неделя. Чутка передохнем, нагрузки будет поменьше!
Реализуем компонент, распределяющий проблемы пользователей (как звучит-то) на менеджеров. О том, что менеджер назначен на какую-то проблему нужно уведомлять не только менеджера, но и пользователя (не зря мы заводили всякие потоки и вебсокеты на прошлой неделе). Но штука не в этом. Здесь не будет привычных тестов, на которые можно опираться. Надо будет написать всё самим, опираясь на словесное описание. Прямо как в реальной жизни
На втором уроке реализуем историю сообщений для менеджера, почти по аналогии с клиентом. Ограничения на видимость будут только слегка другие. Ещё напомним, что у менеджера есть ещё и сам список чатов, чтобы решать проблемы разных пользователей. Надо будет сделать ещё и это. После того, как вы это сделаете, посмотрите, как легко заезжают новые ручки
Вишенка на торте – урок так и называется. Научим менеджера отправлять сообщения. По стандарту заведем: ручку, юзкейс, пару методов в репозитории, outbox-задачу. После реализации можно будет залогиниться клиентом и менеджером, и попробовать попереписываться.
В конце всё должно работать. Здесь мы с вами дошли до MVP, который уже не стыдно показать миру.
07 Неделя седьмая, финальная. Свободное плаванье
На последней седьмой неделе вам будет предоставлена возможность самостоятельно реализовать новые фичи с использованием любых технологий и инструментов, которых требует ваша душа.
08 [IN DEV] Неделя восьмая, дополнительная. Готовимся к проду
Предварительно:
1 Введение
2 Внедрение трейсинга
3 Внедрение мониторинга
4 Подготовка к масштабированию
5 Рубежный контроль
09 [IN DEV] Неделя девятая, дополнительная. Инфраструктура
Предварительно:
1 Введение
2 Знакомство с Kubernetes
3 Развёртывание сервиса в minikube
4 Рубежный контроль
5 Заключение по второй части курса
Показать больше
