Микрофронтенды - это когда большой сайт режут на куски, которые можно деплоить отдельно, но пользователь видит одну страницу. Зачем: разные команды, разный темп релизов, меньше страха «сломали всё одной кнопкой». Цена - сложность сборки, общие стили, общая навигация, производительность.
Ниже - когда модульность окупается, а когда вы просто усложнили жизнь себе любимым.
Большой бизнес и несколько команд
Если у вас три команды и один монолитный фронт, каждый релиз превращается в координацию космического уровня. Модули с чёткими границами снимают часть боли. Если команда одна и релизы редкие - вы ещё не выросли в проблему.
Общие правила игры
Дизайн-система, договорённости по URL, единый способ авторизации, общий мониторинг ошибок. Без этого микрофронтенды превращаются в зоопарк, только теперь деплоится быстрее.
- Версии библиотек - договоритесь, иначе вес страницы взлетит.
- Общий каркас - шапка, футер, меню не должны расходиться визуально.
Производительность
Несколько бандлов, дубли зависимостей, лишние запросы - лечится дисциплиной и инструментами сборки, не «ещё один спринт на рефакторинг когда-нибудь».
Когда не надо
Маленький маркетинговый сайт и одна команда. Там модули на уровне папок в проекте достаточно.
Тестирование
Интеграционные тесты на стыках модулей, контрактные тесты API. Без этого каждый релиз - лотерея, просто теперь быстрая лотерея.
Наблюдаемость
Ошибки должны подсвечиваться с указанием модуля. Иначе ночной дежурный будет гадать, кто виноват, пока клиенты спят нехорошим сном.
Стоимость владения
Несколько пайплайнов, несколько репозиториев, больше DevOps-задач. Заложите это в бюджет заранее, а не «внезапно стало дорого».
Инструменты сборки и зависимости
Единая политика версий webpack/vite, общий lockfile где возможно, запрет «подтянуть библиотеку в обход реестра». Иначе каждый микрофронт привозит свою копию React и вы снова лечите вес страницы, от которого ушли.
Договоритесь о lazy-load границах: что подгружается при переходе, что префетчится заранее. На медленных сетях пользователь почувствует стык модулей раньше, чем вы увидите метрику.
Документация для онбординга разработчиков
Короткий гайд «как добавить новый модуль», шаблон CI, примеры тестов контрактов. Без этого каждый новый человек тратит две недели на «как тут у вас».
Границы модулей по домену, а не по команде
Команды меняются, доменные области — реже. Модуль «каталог», «корзина», «кабинет» живёт дольше, чем «команда Васи».
Общие библиотеки и версии
Зафиксируйте политику обновления дизайн-системы. Иначе каждый микрофронт > свой оттенок кнопки, и витрина выглядит как коллаж.
Роутинг и SSR
Согласуйте, кто отдаёт HTML первого экрана, как делить бандлы, как не грузить десять фреймворков на одну страницу. Иначе модульность есть, скорости нет.
Контракты между командами
API между фронтами, события, общие типы. Линтеры и контракт-тесты дешевле интеграционной драмы на релизе.
Наблюдаемость
Единый трейсинг по пользовательскому пути через микрофронты. Без него баг «на стыке» живёт неделями.
Когда не дробить
Маленькая команда и простой сайт — монолит с модулями внутри часто быстрее в деньгах. Честная оценка «нам не нужен микрофронт» тоже профессионализм.
Разобрать вашу ситуацию - контакты GERS.