вариант хранения все в одной репе, чтобы удобнее было деплоить, фиксы делать, прото файлы юзать и т.п. (помню на GolnagConf 2019 говрили это самый норм вариант) Но что-то подсказывает что это супер костыль, но и отдельно хранить каждый микросервис в отдельной репе радости не приносит.
Да я знаю про эти варианты, но хочется услышать плюсы минусы, в монорепе проще от дублирующкго кода избавиться, а вот на каждый микросервис надо дублировать я либо какой-то common пакет в отдельной репе держать
“избавиться от дублирующего кода” обычно означает “сделать такую жесткую связность, что развивать проект станет невозможно”
С отдельными репа и есть проблема соблюдение версий? По факту если я обновлю какой-то общий пакет мне придётся по всем микросервисами лезть и обновлять его
монорепа и связность - это параллельные понятия,даже если храните код в монорепе, нельзя просто делать импорт из соседней папки
если у вас так все устроено - у вас не микросервисы, а распределенный монолит
Ок, а как тогда выносить общие пакеты типа мидлварей, оберток на трейсинг и т.п Придётся все это дублировать в каждом микросервис?
выносить, но вычищать из них всю бизнес-логику. тогда они будут меняться редко (никогда) а то, что делает бизнес-логику и так дублироваться не должно
Ну по факту сейчас так и есть, внутри репы микросервисы никак не связаны между собой бизнес логикой
ну вот пусть так и остается 🙂
Вот такая ситуация крайне меня огорчает, именно поэтому мы решили все в мнорепу складывать
а как монорепа исправит ситуацию? у вас все еще 3 сервиса, и они все еще зависят от разных версий библиотеки
ну например, сейчас у нас есть пакет для grpc в котором заложена предварительная обработка контекста (вытаскиваем данные из метаданных для логов, трейсинга), так вот этот пакет на этапе разработки регулярно обновляется, а т.к у нас все в монорепе микросервисы автоматом получают обновленный пакет
Обсуждают сегодня