Skip to content

Latest commit

 

History

History
143 lines (120 loc) · 15.1 KB

SPECIFICATION.md

File metadata and controls

143 lines (120 loc) · 15.1 KB
Raw

Выпускной проект Продвинутый Go-разработчик

Введение

В ходе проекта разрабатывается backend для корпоративного новостного портала. Backend портала будет строится на микросервисной архитектуре и включать в себя два сервиса, взаимодействующих друг с другом.

  • User-service: Мастер-сервис, состоящий из CRUD операций с пользовательскими данными портала, а также имеющий функционал регистрации, авторизации и аутентификации пользователя.
  • News-service: Сервис-потребитель, в котором осуществляются операции с новостным контентом.

User Stories

Разрабатываемые сервисы должны позволить реализовать следующие пользовательские истории:

  1. Как редактор новостей, я хочу писать новостной контент и публиковать его для всех пользователей портала, чтобы делится публичной информацией с другими пользователями портала. (Не обязательно в MVP)
  2. Как модератор, я хочу проводить модерацию новостного контента, чтобы проверять публикуемую информацию на соответствие правилам портала. (Не обязательно в MVP)
  3. Как читатель, я хочу читать новостной контент, чтобы знакомиться с публичной информацией на портале.
  4. Как читатель, я хочу лайкать и писать комментарии к новостному контенту, чтобы делиться обратной связью. (Комментарии не обязательно в MVP)
  5. Как пользователь портала, я хочу настраивать свой профиль, указывать информацию о себе, устанавливать аватар, чтобы выделить свою уникальность перед другими пользователями.
  6. Как администратор, я хочу без ограничений управлять новостным контентом, профилями пользователей, их комментариями, чтобы производить сопровождение портала в ходе эксплуатации.

Примечание: Функционал MVP рассчитан на разработку в соло.

Use Cases

Общий сценарий (для неавторизованных и незарегистрированных пользователей)

  1. Пользователь впервые зашел на портал.
  2. Портал распознал пользователя как неавторизованного и предложил авторизоваться.
  3. Пользователь не имеет данных авторизации, и переходит к регистрации.
  4. Портал открыл форму регистрации для пользователя.
  5. Пользователь вводит авторизационные данные.
  6. Портал создал учетную запись и первичный токен авторизации для пользователя.

Общий сценарий (для неавторизованных и зарегистрированных пользователей)

  1. Пользователь впервые зашел на портал.
  2. Портал распознал пользователя как неавторизованного и предложил авторизоваться.
  3. Пользователь ввел свой логин и пароль.
  4. Портал проверил комбинацию логина и пароля и авторизовал пользователя.
  5. Если комбинация неверная, пользователю показана ошибка.

Сценарий написания и публикации контента

  1. Редактор новостей зашел на портал в управление новостями.
  2. Портал проверил, что у редактора есть права на управление новостями.
  3. Если прав нет, система не допустит пользователя к разделу.
  4. Редактор приступил к написанию новой новости и сохранил ее.
  5. Портал сохранил новость на статусе draft.
  6. Редактор опубликовал новость.
  7. Портал перевела новость на статус published или moderation в зависимости от роли редактора (доверенный или не доверенный автор соответственно).

Сценарий модерации контента (Не обязательно в MVP)

  1. Модератор новостей зашел на портал в управлении новостями.
  2. Портал проверил, что у модератора есть права на управление новостями.
  3. Если прав нет, система не допустит пользователя к разделу.
  4. В разделе для модератора доступен дополнительный функционал с показом новостей на модерации.
  5. Модератор просматривает содержание новости и проверяет на соответствие правила портала.
  6. Если замечаний нет, модератор публикует новости.
  7. Если есть замечаний, модератор может редактировать новость или вернуть на статус draft.

Сценарий чтения новостей

  1. Читатель зашел на портал.
  2. Портал открыл ленту новостей, в которой показывается список новостей с их аннотацией.
  3. Читатель может применить настройки к списку новостей:
  4. Пагинация по 10, 25 или 50 новостей;
  5. Фильтрация по автору;
  6. Фильтрация по датам;
  7. Фильтрация предметной области;
  8. При применении настроек к списку, система показывает список новостей с обновленными настройками.
  9. Читатель открывает отдельную статью.
  10. Портал открыл полный контент новости.

Сценарий лайков и комментариев в новости (комментари не обязательно в MVP)

  1. Читатель открыл полный контент новости.
  2. Читатель кликнул на кнопку для проставления лайка.
  3. Портал засчитал новости лайк.
  4. Читатель написал к новости комментарий.
  5. Портал отобразил в новости новый комментарий от читателя.

Сценарий настройки профиля

  1. Любой пользователь портал может открыть свой или чужой профиль.
  2. Портал откроет подробную информацию о профиле.
  3. Если открыт профиль текущего пользователя, то доступен функционал редактирования.
  4. Пользователь при редактировании профиля может изменить информацию о себе и поставить/изменить/удалить аватар.

Функциональные требования

  1. Портал должен иметь функционал регистрации и авторизации пользователя.
  2. У каждого пользователя должен быть определен набор прав, которые ограничивают или расширяют доступный ему функционал на портале.

a. Перечень минимальных прав:

i.	Читатель – возможность чтения новостей, проставление лайков и оставление комментариев. 

ii.	Редактор – доступ к функционалу управления статьями (может управлять только статьями, в которых является автором). Может писать статьи и отправлять на модерацию. (Не обязательно в MVP)

iii.	Доверенный редактор – доступ к функционалу управления статьями (может управлять только статьями, в которых является автором). Может писать статьи и отправлять на публикацию без модерации. (Не обязательно в MVP)

iv.	Модератор – в функционале управления статьями доступен функционал по модерации новостей. Может опубликовать новость на модерации, внести в нее изменения, отправить в draft. (Не обязательно в MVP)

v.	Администратор – может просматривать, редактировать и удалять любой контент портала. Может назначать и снимать права у других пользователей. Может изменять профиль других пользователей.
  1. На портале должно быть возможность размещать новостной контент.
  2. На каждую новость должна быть возможность оставлять комментарии и лайкать. (комментари не обязательно в MVP)
  3. По каждому пользователю портала должна быть доступна информация, которую пользователь о себе оставил, а также показываться его аватар (при наличии).
  4. Пользователь может редактировать свой профиль и устанавливать аватар в виде изображений в формате jpeg и png.

Нефункциональные требования

  1. Часть функционала по авторизации и управлению пользователями должна быть переиспользуема и расширяема для возможности подключения дополнительных сервисов и функционала.
  2. Авторизация пользователей должна производиться по REST API и выполнена с использованием JWT Токена. Передаваться токен должен через cookie или header.
  3. Межсервисное взаимодействие должно происходить через gRPC.

BE интерфейсы (ориентировочные)

User-service REST

  • Авторизация (передается логин и пароль, и при верной комбинации возвращается токен);
  • Регистрация (передается логин и пароль, возвращается токен) User-service gRPC
  • Верификация пользователя по токену (возвращает информацию о пользователей и его правах);
  • Получить список пользователей;
  • Получить детализацию пользователя по ID;
  • Создать пользователя;
  • Редактировать пользователя;
  • Удалить пользователя;
  • Загрузить аватар пользователя;
  • Удалить аватар пользователя; News-service REST
  • Получить список новостей (с информацией об авторе и количеством лайков/комментариев);
  • Получить детализацию новости (с лайками, комментариями и авторами комментариев);
  • Создать новость;
  • Редактировать новость;
  • Удалить новость;
  • Создать лайк;
  • Удалить лайк;
  • Создать комментарий (с информацией об авторе);
  • Удалить комментарий;

Комментарий от ментора

Привет! 
1. Провалидируй еще раз, чтобы REST был для взаимодействия пользователя (браузера) с бэкэндом, а для взаимодействия сервисов между собой - gRPC
2. Давай добавим асинхронный воркер какой-нибудь. Например, сделаем ручку для получения самых залайканных постов (этот список должен формироваться в фоне не синхронно) ЛИБО сделаем удаление постов старее месяца (на твое усмотрение)
3. Предлагаю порезать роли (их много, оставим админа и читателя), убрать возможность комментирования и удаления новостей
В остальном выглядит отлично. Если все успеем, то лучше добавим функционал (роли, комментарии и т д)

Аватарки тоже можно не сразу добавлять, а если время останется. Чтобы все время не ушло на работу с объектным хранилищем

JWT приватный ключ в юзер сервисе, публичный ключ в новостном
Хендлеры для админки на отдельном порту
Роуты с админкой на отдельном закрытом порту