| Приоритет | Фича |
|---|---|
| Блокер | Автор может создать спецификацию |
| Блокер | Любой пользователь может поделиться ссылкой на доступную спеку |
| Блокер | Любой пользователь может поделиться ссылкой на спеку |
| Блокер | Любой пользователь может поделиться ссылкой на спеку |
Идея проекта: я, как backend разработчик, могу создать OpenAPI спецификацию, выложить этот OpenAPI публично по ссылке, поделиться этой ссылкой, что бы frontend разработчик мог посмотреть его и написать комментарий к какой-либо строчке из этого OpenAPI, тем самым обсудить и согласовать спецификацию.
Должен быть один gateway для веба. Генерируемый gateway из OpenAPI со следующими endpoints:
CRUD для работы с openapi спецификацией(физически файл храним в s3, нужна интеграция), возвращаем только ссылку на него и другие нужные поля.
GET item метод возвращает спецификацию и все комментарии к ней
CRUD для работы с комментариями для спецификации
Endpoints для авторизации пользователя
3 микросервиса(можете организовать свою структуру, это только предложение):
Авторизация
Пользователи
Работа с OpenAPI и комментариями
Создать OpenAPI и оставить комментарий может только юзер после аутентификации по логину/паролю(и по Google OAuth, но это задание со звёздочкой).
Комментарии должны иметь иерархию. Под первым комментарием мы можем оставить второй, и так далее, предусмотреть это для сортировки на frontend. Комментарий может удалить только пользователь его оставивший.
Задание со звёздочкой. Реализовать версионность загружаемых OpenAPI спецификаций. Загрузили первую спецификацию - обсудили, оставив комментарии. Я загрузил новую версию этой спецификацию(вызвал метод обновления из crud для спецификации), далее frontend должен мочь получить нужную спецификацию по версии(какая именно версионность на ваше усмотрение). Комментарии так же привязываются не только к спецификации, но и к ее версии.
Стек, который можно использовать - все, что есть в учебном проекте: go, OpenAPI с генераций, gRPC, protobuf, entgo, все пакеты из pkg, другие пакеты(обосновать их использование в README.md)
Должен проходить ci. Должны быть реализованы тесты в рамках каждого микросервисы и end to end тесты.
Описать сервис README.md, добавить ADR с критичными на ваш взгляд архитектурными решениями, нарисовать Implementation/Developer view UML схему.
Написать docker-compose файл для локальной развертки проекта. (отредактировано)