Тут все на так однозначно: нужно считать.
Такой же аргумент часто используют против переезда из глубинки в дефолт сити. Но на собственном примере могу сказать, что возможен следующий вариант: зарплата увеличилась в 2 раза, аренда — в 2 раза, но и остаток тоже увеличился в 2 раза.
Кроме того, есть большое количество товаров, которые стоят плюс/минус одинаково в любой точке мира (а многие, как например Айфоны, в США даже дешевле, чем в России, то же самое с автомобилями, путешествиями и прочим). Хотя сфера услуг конечно сильно дороже в более развитых регионах.
Название аккаунта как бы намекает — monorepi — это латинское словообразование множественного числа. Т.е. это шуточный аккаунт их 2х монорепозиторий.
Ну и прочитайте статью, там первая половина как раз посвящена истории того, как так вышло
Да не нужно вам ходить по репам, в больших компаниях все равно у каждой команды свой сервис. В лучшем случае вам понадобится ваш репозиторий и, возможно, парочка соседних для интеграционного тестирования.
Думаю, что это может быть связано, но далеко не всегда. Но в оригинальной статье автор говорит о том, что монорепозиторий провоцирует плохую архитектуру и отсутствие декомпозиции.
В целом вы правы, но при подходе share nithing можно вообще ничего не хранить — каждый сервис содержит свою актуальную swagger-спецификацию, которую клиенты используют и обновляют.
Я хочу отметить, что если разговор о больших компаниях, то чаще всего отдельные сервисы разрабатываются отдельными командами. Поэтому все равно, если вы решите изменить API своего сервиса, вы не сможете переписать код всех клиентов, просто потому, что вы его не знаете и не владеете им. Поэтому, вы просто сообщаете другим командам, что у вас появились новые методы в API, но оставляете старые как deprecated.
А вообще ещё лучше делать все изменения обратно совместимыми. Если у вас API публичный, вы не владеете кодом клиентов и не можете заставить их его обновить, у вас собственно и нет других вариантов.
Это правда, в этом и проблема, что такие инструменты как GitHub предназначены прежде всего для маленьких команд, коих сейчас огромное число. И так почти со всеми инструментами. И это неспроста — это диктует рынок.
В случае же кучи микрорепозиториев вы обрекаете себе на ад микроменеджмента зависимостей между ними.
Я работал в парадигме share-nothing, там такой проблемы нет совсем. Т.к. зависимостей между микросервисами нет. А если сервисы тесно связаны, их нужно хранить вместе.
Тут все на так однозначно: нужно считать.
Такой же аргумент часто используют против переезда из глубинки в дефолт сити. Но на собственном примере могу сказать, что возможен следующий вариант: зарплата увеличилась в 2 раза, аренда — в 2 раза, но и остаток тоже увеличился в 2 раза.
Кроме того, есть большое количество товаров, которые стоят плюс/минус одинаково в любой точке мира (а многие, как например Айфоны, в США даже дешевле, чем в России, то же самое с автомобилями, путешествиями и прочим). Хотя сфера услуг конечно сильно дороже в более развитых регионах.
Не упомянут вопрос про многокилометровые пробки и вообще большое перенаселение.
То, что у каждой отдельной деревушки есть свое название — дань традициям
Название аккаунта как бы намекает — monorepi — это латинское словообразование множественного числа. Т.е. это шуточный аккаунт их 2х монорепозиторий.
Ну и прочитайте статью, там первая половина как раз посвящена истории того, как так вышло
mastodon.technology/@robey/101349183169527275
Слышали про twitter.com/monorepi?lang=en — это от Твиттера, у них было 2 монорепозитория :)
Для справки www.gigamonkeys.com/flowers
Конфиг хороший — МакБук Про.
И скорее всего мне нужен весь репозиторий (ведь если он весь собирается одним билд тулом), а не его часть
Мастер-то, ясно дело, линейный (почти:)
Я хочу отметить, что если разговор о больших компаниях, то чаще всего отдельные сервисы разрабатываются отдельными командами. Поэтому все равно, если вы решите изменить API своего сервиса, вы не сможете переписать код всех клиентов, просто потому, что вы его не знаете и не владеете им. Поэтому, вы просто сообщаете другим командам, что у вас появились новые методы в API, но оставляете старые как deprecated.
А вообще ещё лучше делать все изменения обратно совместимыми. Если у вас API публичный, вы не владеете кодом клиентов и не можете заставить их его обновить, у вас собственно и нет других вариантов.
Я работал в парадигме share-nothing, там такой проблемы нет совсем. Т.к. зависимостей между микросервисами нет. А если сервисы тесно связаны, их нужно хранить вместе.