бекенд монолит (но странный, ниже опишу почему), фронт приложение и ряд отдельных микросервисов. Инфраструктура полностью на AWS.
Проект достался по наследству, уже успели внести ряд новых фич (как в старые сервисы, так и новые). Сейчас стал вопрос, что что-то нужно делать с бекенд монолитом. Странный он по той причине, что он не совсем монолит), а скорее кодовая база хранится как монорепозиторий. То есть в этом репозитории 3 отдельных сервиса, которые разварачиваются на aws отдельно, но при этом у них общая БД. Мы думаем окончательно его поделить на 3 сервиса, то есть вынести в разные репозитории, в ходе переноса отрефакторить код, но вот что делать с БД? По хорошему конечно ее нужно дробить, чтобы для каждого сервиса была своя БД, но пока не ясно оправдано ли это делать сейчас.
Ну и вопрос (совет) заключается в том, стоит ли сейчас пилить этот псевдомонолит (монорепозиторий) с общей БД на полноценно отдельные сервисы или пока если нет времени и нужды в деление самой БД, то в рамках этого монорепозитория просто рефакторить код. Или все же норм решение полноценно разделить на разные репозитории, но при этом остается общая БД. И потом постепенно по возможности, что-то делать с БД.
Зачем
Ну на данный момент команда небольшая, поэтому с точки зрения упрощения разделения ответственности между командами нет нужды. Мысль эта пришла поскольку они и так отдельные сервисы с точки зрения деплоя (но БД общая) + рефакторить или вносить изменения могут разные люди для каждого сервиса. И чтобы убрать вероятность, что затронет и другой сервис. Но опять же, так как пока команда небольшая, то проблема не существенная.
Общая БД физически — не плохо. Общая БД логически — могут быть проблемы. Однако, в монорепе это можно контролировать. Как уже тысячу раз тут говорилось, в (микро)сервисах нет никакой иной идеи кроме независимого деплоя (при этом, монорепозиторий это не отрицает есличо). Все попытки "развязать сервисы" и сделать потому что модно и красиво разбиваются о лишнюю сложность, которую эти сервисы принесут
ну сейчас по большей часть общая БД на физическом уровне. Только данные по юзерам могут использоваться в нескольких, но это решаемо. Тем более уже используется JWT токен, где хранятся некоторые данные юзера, чтобы каждый раз не ходить в БД
В JWT довольно опасно хранить "некоторые" данные юзера, т.к. все выданные JWT валидны вплоть до даты истечения. Самый упоротый пример: хранить в JWT баланс юзера. Юзер получает JWT, там {"user_id": 123, "balance": "1000.00"}, покупает что-то на 900, ему выдают новый JWT {"user_id": 123, "balance": "100.00"}, но exp старого ещё не подошёл к now. Юзер подкидывает вам опять старый JWT с balance=1000. Вуаля, вас хакнули
такую инфу мы не храним) спасибо за совет
Обсуждают сегодня