DP
Я знаю что go.mod фацлы можно положить в сами папки с микросервисами но зависимости будут повторяться, хз как правильно
будут повторяться, но вас это беспокоить не должно - они кешируются
Size: a a a
2020 October 06
RL
Да я знаю про эти варианты, но хочется услышать плюсы минусы, в монорепе проще от дублирующкго кода избавиться, а вот на каждый микросервис надо дублировать я либо какой-то common пакет в отдельной репе держать
Из плюсов отдельных сервисов - проще кодить, потому что меньше кода в одном сервисе. Меньше проблем с мержем кода.
Минус - надо копировать общие структуры либо делать репу с общим кодом
Минус - надо копировать общие структуры либо делать репу с общим кодом
DP
Да я знаю про эти варианты, но хочется услышать плюсы минусы, в монорепе проще от дублирующкго кода избавиться, а вот на каждый микросервис надо дублировать я либо какой-то common пакет в отдельной репе держать
“избавиться от дублирующего кода” обычно означает “сделать такую жесткую связность, что развивать проект станет невозможно”
NK
Из плюсов отдельных сервисов - проще кодить, потому что меньше кода в одном сервисе. Меньше проблем с мержем кода.
Минус - надо копировать общие структуры либо делать репу с общим кодом
Минус - надо копировать общие структуры либо делать репу с общим кодом
С отдельными репа и есть проблема соблюдение версий? По факту если я обновлю какой-то общий пакет мне придётся по всем микросервисами лезть и обновлять его
ВГ
Да я знаю про эти варианты, но хочется услышать плюсы минусы, в монорепе проще от дублирующкго кода избавиться, а вот на каждый микросервис надо дублировать я либо какой-то common пакет в отдельной репе держать
монорепа и связность - это параллельные понятия,даже если храните код в монорепе, нельзя просто делать импорт из соседней папки
DP
С отдельными репа и есть проблема соблюдение версий? По факту если я обновлю какой-то общий пакет мне придётся по всем микросервисами лезть и обновлять его
если у вас так все устроено - у вас не микросервисы, а распределенный монолит
NK
если у вас так все устроено - у вас не микросервисы, а распределенный монолит
Ок, а как тогда выносить общие пакеты типа мидлварей, оберток на трейсинг и т.п Придётся все это дублировать в каждом микросервис?
NK
Естественно подключения к бд, конфиги не выносятся в отдельный пакет
ВГ
прикол монорепы имхо в том, что у вас есть версия приложения, которая гарантированно работает - внутри одного коммита. Для разных реп нужно делать что-то вроде матрицы версий, и эта матрица может быть довольно жирной
DP
Ок, а как тогда выносить общие пакеты типа мидлварей, оберток на трейсинг и т.п Придётся все это дублировать в каждом микросервис?
выносить, но вычищать из них всю бизнес-логику.
тогда они будут меняться редко (никогда)
а то, что делает бизнес-логику и так дублироваться не должно
тогда они будут меняться редко (никогда)
а то, что делает бизнес-логику и так дублироваться не должно
DP
прикол монорепы имхо в том, что у вас есть версия приложения, которая гарантированно работает - внутри одного коммита. Для разных реп нужно делать что-то вроде матрицы версий, и эта матрица может быть довольно жирной
это, коллега, совершенно не так 🙁
ВГ
это, коллега, совершенно не так 🙁
нет так!
NK
выносить, но вычищать из них всю бизнес-логику.
тогда они будут меняться редко (никогда)
а то, что делает бизнес-логику и так дублироваться не должно
тогда они будут меняться редко (никогда)
а то, что делает бизнес-логику и так дублироваться не должно
Ну по факту сейчас так и есть, внутри репы микросервисы никак не связаны между собой бизнес логикой
DP
Ну по факту сейчас так и есть, внутри репы микросервисы никак не связаны между собой бизнес логикой
ну вот пусть так и остается 🙂
RL
С отдельными репа и есть проблема соблюдение версий? По факту если я обновлю какой-то общий пакет мне придётся по всем микросервисами лезть и обновлять его
Не совсем.
Если обновляется общий пакет, то надо обновлять все сервисы, которых этот пакет касается.
То есть вполне возможна ситуация, когда
сервис1 и сервис2 зависят от common v1.3.0, а сервис3 зависит от common v1.1.2
Если обновляется общий пакет, то надо обновлять все сервисы, которых этот пакет касается.
То есть вполне возможна ситуация, когда
сервис1 и сервис2 зависят от common v1.3.0, а сервис3 зависит от common v1.1.2
NK
Не совсем.
Если обновляется общий пакет, то надо обновлять все сервисы, которых этот пакет касается.
То есть вполне возможна ситуация, когда
сервис1 и сервис2 зависят от common v1.3.0, а сервис3 зависит от common v1.1.2
Если обновляется общий пакет, то надо обновлять все сервисы, которых этот пакет касается.
То есть вполне возможна ситуация, когда
сервис1 и сервис2 зависят от common v1.3.0, а сервис3 зависит от common v1.1.2
Вот такая ситуация крайне меня огорчает, именно поэтому мы решили все в мнорепу складывать
NK
+ деплоить намного проще
NK
И разрабатывать
DP
Вот такая ситуация крайне меня огорчает, именно поэтому мы решили все в мнорепу складывать
а как монорепа исправит ситуацию?
у вас все еще 3 сервиса, и они все еще зависят от разных версий библиотеки
у вас все еще 3 сервиса, и они все еще зависят от разных версий библиотеки
NK
а как монорепа исправит ситуацию?
у вас все еще 3 сервиса, и они все еще зависят от разных версий библиотеки
у вас все еще 3 сервиса, и они все еще зависят от разных версий библиотеки
ну например, сейчас у нас есть пакет для grpc в котором заложена предварительная обработка контекста (вытаскиваем данные из метаданных для логов, трейсинга), так вот этот пакет на этапе разработки регулярно обновляется, а т.к у нас все в монорепе микросервисы автоматом получают обновленный пакет