Цель: В результате выполнения ДЗ должен получиться базовый скелет микросервиса, который будет развиваться в дальнейших ДЗ. Структура кода должна соответствовать подходу Clean Architecture.
В данном задании тренируются навыки:
- декомпозиции предметной области;
- построения элементарной архитектуры проекта.
Завести в репозитории отдельную директорию для проекта "Календарь" Создать внутри структуру директорий, соответствующую Clean Architecture.
Cоздать модели (структуры) календаря. Cоздать методы бизнес логики (методы у структур) для работы с этими структурами:
- добавление событий в хранилище
- удаление событий из хранилища
- изменение событий в хранилище
- листинг событий
- пр. на усмотрение студента
Создать объекты ошибок (error sentinels) соответсвующие бизнес ошибкам, например ErrDateBusy - данное время уже занято другим событием. Реализовать хранение событий в памяти (т.е. просто складывать объекты в слайсы) Реализовать Unit тесты проверяющие работу бизнес логики (в частности ошибки).
На данном этапе не нужно:
- Делать HTTP, GRPC и пр. интерфейсы к микросервису
- Писать .proto-файлы (это будет позже)
- Использовать СУБД
Критерии оценки: Критерии оценки:
- Созданы структуры, необходимые для реализации календаря
- Соблюдены принципы Clean Architecture
- Работа с хранилищем через интерфейс
Код должен проходить проверки go vet и golint.
У преподавателя должна быть возможность скачать и проверить пакет с помощью go get / go test.
Цель: Реализовать HTTP интерфейс для сервиса Календаря.
Тех. задание: https://github.com/OtusTeam/Go/blob/master/project-calendar.md
Цель данного задания - отработать навыки работы со стандартной HTTP библиотекой, поэтому технологии JSONRPC,
Swagger и т.п. НЕ используются. В директории с проектом создать отдельный пакет для Web-сервера. Реализовать
вспомогательные функции для сериализации объектов доменной области в JSON. Реализовать вспомогательные функции
для парсинга и валидации параметров методов /create_event и /update_event. Реализовать HTTP обработчики для каждого
из методов API, используя вспомогательные функции и объекты доменной области. Реализовать middleware
для логирования запросов.
Методы API:
POST /create_event
POST /update_event
POST /delete_event
GET /events_for_day
GET /events_for_week
GET /events_for_month
Параметры передаются в виде www-url-form-encoded (т.е. обычные user_id=3&date=2019-09-09)
В GET методах параметры передаются через queryString, в POST через тело запроса.
В результате каждого запроса должен возвращаться JSON документ содержащий
- либо {"result": "..."} в случае успешного выполнения метода
- либо {"error": "..."} в случае ошибки бизнес-логики
Критерии оценки: Все методы должны быть реализованы
Бизнес логика (пакет internal/domain в примере) НЕ должен зависеть от кода HTTP сервера
В случае ошибки бизнес-логики сервер должен возвращать HTTP 200
В случае ошибки входных данных (невалидный int например) сервер должен возвращать HTTP 400
В случае остальных ошибок сервер должен возвращать HTTP 500
Web-сервер должен запускаться на порту указанном в конфиге и выводить в лог каждый обработанный запрос.
Цель: Создать GRPC API для сервиса календаря.
Цель данного занятия: отработка навыков работы с GRPC, построение современного API.
Создать отдельную директорию для Protobuf спек.
Создать Protobuf спеки с описанием всех методов API, их объектов запросов и ответов.
Т.к. объект Event будет использоваться во многих ответах разумно выделить его в отдельный message.
Создать отдельный директорию для кода GRPC сервера.
Сгенерировать код GRPC сервера на основе Protobuf спек (скрипт генерации сохранить в репозиторий).
Написать код, связывающий GRPC сервер с методами доменной области.
Критерии оценки: Все методы должны быть реализованы.
Бизнес логика (пакет internal/domain в примере) НЕ должен зависеть от кода GRPC сервера.
GRPC-сервер должен запускаться на порту указанном в конфиге и выводить в лог каждый обработанный запрос.
У преподавателя должна быть возможность заново сгенерировать код по Protobuf спекам.
Цель: Обеспечить сохранение событий календаря в СУБД
Цель данного занятия: отработка навыков работы СУБД, SQL, пакетами database/sql и github.com/jmoiron/sqlx
- Установить базу данных (например postgres) локально (или сразу в Docker, если знаете как)
- Создать базу данных и пользователей для проекта календарь
- Создать схему данных (таблицы, индексы) в виде отдельного SQL файла и сохранить его в репозиторий
- В проекте календарь создать отдельный пакет, отвечающий за сохранение моделей в СУБД
- Настройки подключения к СУБД вынести в конфиг проекта
- Изменить код приложения так, что бы обеспечить сохранение событий в СУБД
Критерии оценки: Должны быть созданы все необходимые таблицы и индексы.
SQL миграция должна применять с первого раза и должна быть актуальной, т.е. все изменения которые вы делали в своей
базе должны быть отражены в миграции. Бизнес логика (пакет internal/domain в примере) должна использовать модуль
для работы с СУБД через интерефейсы.
Цель: Реализовать "напоминания" о событиях с помощью RabbitMQ.
Цель данного занятия: отработка навыков работы с RabbitMQ и очередями вообще.
Установить локально очередь сообщений RabbitMQ (можно сразу в Docker если знаете как)
Создать процесс (scheduler), который периодически сканирует основную базу данных, выбирая события о которых нужно напомнить. При запуске процесс должен подключаться к RabbitMQ и создавать все необходимые структуры (топики) в ней. Процесс должен выбирать сообытия для которых следует отправить уведомление, сериализовать их (например в JSON) и складывать в очередь.
Создать процесс (sender), который читает сообщения из очереди и шлет уведомления. Непосредственно отправку делать не нужно - можно просто выводить сообщения в STDOUT.
Критерии оценки: Настройки подключения к очереди должны быть вынесены в конфиг проекта.
У преподавателя должна быть возможность скомпилировать процессы scheduler и sender с помощью Makefile.
После запуска RabbitMQ и PostgreSQL процессы scheduler и sender должны запускаться без дополнительных
действий.