Комментарии 4
Елизавета, в плюсы Вами вынесено “не нужно согласовывать взаимное влияние модулей". Без уточнений.
Нужно понимать, что переход полностью устранил это влияние? Изменение длины поля “Наименование" в модуле “Каталог“ уже можно провести без согласования с модулем "Заказы"? И получить в скором времени знаменитые "пельмени бабушкины останки"?
Не. Всё понятно с плюсами то. Но и о минусах стоит говорить. Особенно аналитикам :)))
Привет! Ответ от автора) "К сожалению, не знаю мем (если это мем конечно) про "пельмени бабушкины останки", но надеюсь в полной мере ответить на вопрос)
Влияние команд друг на друга формализуется в контрактах. Плюс микрофронтов в том, что это согласование происходит четко и явно на уровне интерфейсов, а не растворено в общем коде монолита, где все могут менять что угодно и когда угодно. Изолированность позволяет менять внутреннюю реализацию фронта без согласования, но не его публичные интерфейсы
А про минусы постаралась раскрыть в статье после слов "А появились ли новые проблемы?))) Конечно!""
Микрофронтенды это наверное хорошо. Если правильно понял из-за выбора этого подхода вам пришлось пересмотреть процессы чтобы решить проблемы и получить сверху новых из-за этого подхода? И разбиение на несколько репозиториев совсем не обязательное условие, хотя позволяет проще разграничивать политики между командами. Практика показывает что после разбиения 1 монолитного репозитория на несколько через 2 года сливают обратно в 1 чтобы избежать проблемы синхронизации версий и деплоя измененний одновременно. Интересно через сколько вы вернётесь к 1 репозиторию устав от согласования сборок и версий и поддержания тысячи пайплайнов.
Привет! От автора) "Процессы мы пересмотрели: у нас ушло много кросс командных взаимодействий, каждая команда стала более изолированной и автономной. Из новых проблем: для реализации нового микрофронта (далее МФ) добавилось больше бюрократии (обоснования, нагрузки и тд), но это все решаемо и новые МФ появляются не так часто. Остальные проблемы по типу больше точек сборки, согласование контрактов и тд мы и так имели с точки зрения работы с бэком, поэтому тут организационные процессы аналогичные, мы с ними знакомы и внедрили быстро
На остальное дам общий комментарий) Насчет репозиториев — вы попали в точку. Polyrepo (несколько репозиториев) — это выбор, а не догма. Мы выбрали его для жесткого разграничения команд и независимого жизненного цикла каждого микрофронтенда. Однако вы абсолютно правы, что Monorepo — это сильная альтернатива, которая решает проблемы синхронизации версий и сборки. Переходить на Monorepo пока разговоров нет, но как только начнутся, можно про это тоже выпустить статью 😁 Обязательно расскажу, если до этого дойдем"
Пилим монолит на… микрофронты (часть 2)