Принято считать, что если фронтенд стал большим и тяжёлым,
значит пора пилить его на микрофронтенды.
Звучит логично.
👉 большой монолит — плохо
👉 много маленьких приложений — хорошо
На практике всё чуть сложнее.
Микрофронтенды не чинят плохие границы
Если в монолите непонятно:
👉 где заканчивается одна фича
👉 где начинается другая
👉 кому принадлежит состояние
👉 кто отвечает за общие зависимости
После нарезки лучше не станет.
Просто хаос переедет
из одной кодовой базы в несколько.
Проблема часто не в размере
Большой фронтенд сам по себе не проблема.
Проблема, когда:
👉 любая правка ломает соседний экран
👉 команда боится трогать shared
👉 релиз одной фичи блокирует остальные
👉 архитектура держится на устных договорённостях
Это не лечится микрофронтендами автоматически.
Микрофронтенды добавляют свою цену
Вместо одного приложения появляется набор новых задач:
👉 версионирование контрактов
👉 общая авторизация
👉 дизайн-система
👉 роутинг между частями
👉 observability
👉 деплой и rollback
И всё это тоже нужно поддерживать.
Когда они реально помогают
Микрофронтенды имеют смысл, если:
👉 команды независимы
👉 доменные границы уже понятны
👉 части продукта можно релизить отдельно
👉 есть зрелая платформа и инфраструктура
Сначала нужны границы.
Потом — микрофронтенды.
Не наоборот.
Частая ошибка
Команда берёт микрофронтенды
как способ «разобраться с монолитом».
Но если вы не можете выделить модуль внутри одного репозитория,
вы не сможете нормально выделить его в отдельное приложение.
Физическое разделение не заменяет архитектурное.
Что попробовать до микрофронтендов
👉 разделить проект по фичам
👉 навести порядок в shared
👉 описать владение модулями
👉 ограничить зависимости
👉 сделать независимые релизные зоны внутри монолита
Иногда этого уже достаточно.
Главная мысль
Микрофронтенды — это не лекарство от монолита.
Это способ масштабировать уже понятные границы.
Если границ нет,
вы получите не распределённую архитектуру,
а распределённый беспорядок.
