Архітектура проєкту
Мапа всіх сервісів і їх взаємодій. Тут описуємо топологію — хто з ким говорить і яким каналом. Глибина окремого сервісу — у його власному <service>/docs/.
Сервіси
| Сервіс | Тип | Роль у системі |
|---|---|---|
| stack | Бек, точка входу | Оркестратор, auth, маршрутизація між проєктами |
| stack-client | Фронт (web) | Веб-інтерфейс для всіх ролей |
| stack-electron | Електрон-клієнт | Робоче місце оператора |
| stack-golden | Бек | Логіка проєкту goldenbride |
| stack-prime | Бек | Логіка проєкту prime |
| stack-udate | Бек | Логіка проєкту udate |
| stack-chathouse | Бек | Логіка проєкту chathouse |
| stack-academy | Бек | Внутрішня школа |
| stack-ai | Бек | AI-функції |
stack-commons | Бібліотека | Спільні middleware, types, утиліти. Власних docs не має. |
Сервіси
golden / prime / udate / chathouseструктурно схожі — кожен реалізує бізнес-логіку для свого партнерського проєкту. Мінімальний план Family-беку (стандартні сервіси, очікуваний партнерський API, кандидати на спільний мікросервіс) — у Family Blueprint.
Канали взаємодії
- HTTP — синхронні виклики, переважно фронт ↔ бек і electron ↔ бек.
- RMQ — асинхронна шина для обміну подіями між бек-сервісами. (TODO: задокументувати схему черг)
- Спільна БД / Redis / ClickHouse — усі бек-сервіси пишуть в одну Mongo-базу
stack. Знімок її стану (розміри, індекси, кандидати на чистку) — у DB Analysis. (TODO: де які стори, що шарується)
Auth і ролі
Авторизація проходить через stack, видається JWT. Кожен бек-сервіс розгортає MiddlevareAuth (з stack-commons) який кладе req.user якщо токен валідний — не блокуючи запит без токена. Захист на рівні ендпоінта — через guard([roles]).
Ролі — у roles.
API
Карта Swagger-ів усіх сервісів + єдина конвенція відповідей + нюанси гвардів — у API Map.
Інфраструктура доки
- Docs Pipeline — як
stack-docsрендериться у сайтdocs.besocial.tech - Quartz v5 Migration — чому ми на Quartz v4.5.2 і план переходу на v5