Практика микрофронтендов быстро убирает романтику из идеи декомпозиции. Как только продукт делится на вертикальные срезы, на поверхность выходят маршрутизация, общие зависимости, координация релизов и вопрос, кто за что действительно отвечает.
Эта глава показывает, что композиция фронтенда требует не только технических трюков, но и устойчивой операционной модели. Миграция с монолитного SPA здесь выглядит не как разрезание кода, а как перестройка интеграции между командами и частями интерфейса.
В ревью и интервью материал полезен, когда нужно отличать полезную декомпозицию от дорогой иллюзии независимости. Он помогает обсуждать оболочку приложения, общие контракты, релизную автономию и границу, после которой свобода команд начинает конфликтовать с цельным пользовательским опытом.
Практическая польза главы
Практика проектирования
Переводите идеи книги в решения по оболочке приложения, моделям композиции, платформенному контракту и границам доменных модулей.
Качество решений
Проверяйте архитектуру по автономии команд, совместимости контрактов, наблюдаемости релизов и цене интеграции.
Аргументация на интервью
Стройте ответ как цепочку: доменные границы → общий слой → модель композиции → миграция → риски эксплуатации.
Формулировка компромиссов
Показывайте цену независимости: общий код, координация релизов, бюджет производительности и поддержка старых контрактов.
Официальный источник
Micro Frontends in Action
Книга о микрофронтендах, моделях композиции, платформенном слое и миграции с монолитного одностраничного приложения (SPA).
Micro Frontends in Action
Авторы: Michael Geers
Издательство: Manning Publications, 2020
Объём: 296 страниц
Michael Geers о микрофронтендах: моделях композиции, платформенном слое, автономии команд и миграции с монолитного SPA.
Книга рассматривает не как набор маленьких приложений, а как способ связать архитектуру интерфейса со структурой команд. В центре находятся продукта, , модели и общий платформенный слой.
Польза начинается с момента, когда команда садится и явно описывает : маршрутизацию, сессию, , дизайн-токены, независимые релизы и . Пропустить этот шаг — и микрофронтенды превращаются в дорогой способ распределить хаос между командами.
Архитектурная карта микрофронтендов
Схема показывает, как микрофронтенд становится частью продукта: где происходит композиция, что держит оболочка и как команда выпускает изменения без большого общего релиза.
Путь
Где собирается единый пользовательский опыт
Композиция может происходить на сервере, в браузере во время выполнения или на этапе сборки. Выбор определяет скорость первого экрана, автономию команд и цену интеграции.
Вход
Пользователь открывает маршрут
Маршрут определяет, какие доменные части нужны для страницы.
Каркас
Оболочка выбирает модель сборки
Сервер отдаёт готовый HTML, браузер загружает модули во время выполнения или сборка заранее склеивает артефакт.
Домены
Микрофронтенды поставляют свои фрагменты
Каталог, корзина, профиль и оформление заказа остаются в границах команд-владельцев.
Опыт
Пользователь видит цельный экран
Платформа скрывает швы, но сохраняет независимость доменных частей там, где она действительно нужна.
Архитектурный смысл
Когда смотреть сюда
- Нужно выбрать между серверной, клиентской и сборочной композицией.
- Есть спор между быстрым первым экраном и независимыми релизами.
- Команда не понимает, где проходит граница ответственности оболочки.
Модель композиции нельзя выбирать только по технологии. Её выбирают по продуктовым маршрутам, требованиям к SEO, скорости первого экрана и зрелости платформенной команды.
Главная идея книги
Микрофронтенд — это не «много маленьких React-приложений», а самостоятельная продуктовая часть с понятным владельцем, границами данных и релизным циклом. Команды получают автономию только тогда, когда принимают общие правила платформы и отвечают за пользовательский сценарий целиком.
Модели композиции
Композиция на сервере
Оболочка собирает фрагменты до отправки страницы и отдаёт единый HTML. Выигрыш — SEO, быстрый первый экран и централизованный контроль маршрутов. Цена — команды сильнее завязаны на серверный контур и релизятся в его ритме.
Композиция в браузере во время выполнения
загружает доменные модули уже в браузере. Каждая команда релизит свой кусок независимо — за это платят дисциплиной: совместимостью версий, бюджетом клиентского кода и аккуратной обработкой сбоев загрузки.
Композиция на этапе сборки
Все доменные части собираются в один артефакт заранее. Стартовать и отлаживать так проще всего, но независимость релизов исчезает: правка в одном домене тянет за собой общий цикл сборки и выпуска.
Что должно быть общим платформенным слоем
Платформенный контракт
- Правила маршрутизации и совместимость глубоких ссылок.
- Граница и безопасная передача контекста между модулями.
- Единая : клиентские метрики, логи, трассировка и связь с версией релиза.
- и базовые UI-примитивы без складирования бизнес-логики в общем пакете.
Командная модель
- закреплена за бизнес-доменами, а не за техническими слоями UI.
- У каждого есть свой цикл разработки, проверки и выпуска.
- версионируются, а устаревшие варианты выводятся из эксплуатации по понятному регламенту.
- Архитектурные ревью проверяют границы модулей, а не превращаются в ручное согласование каждого релиза.
Практический план миграции
- Выделить во фронтенде: каталог, корзину, оформление заказа, профиль и другие самостоятельные сценарии.
- Ввести и минимальный : маршруты, сессию, наблюдаемость, дизайн-токены и правила совместимости.
- Переносить зоны постепенно через , не переписывая всё за один релиз.
- Стабилизировать интеграцию через , версионирование общих API и проверку совместимости перед выпуском.
- Закрепить владельцев, , правила изменения и срок поддержки старых контрактов.
Антипаттерны
- Дробить фронтенд по UI-библиотекам вместо бизнес-доменов и пользовательских сценариев.
- Создать десятки и потерять автономность команд.
- Не договориться о для маршрутов, сессии, телеметрии и базового UI.
- Мигрировать унаследованный фронтенд через вместо управляемого переноса маршрутов.
- Игнорировать и суммарный вес клиентских модулей.
Связанные главы
- Building Micro-Frontends - даёт базовую модель: доменная декомпозиция, границы ответственности и первые принципы для миграции.
- The Art of Micro Frontends - расширяет прикладной подход до зрелой платформы: управление контрактами, оркестрация и операционные практики для больших организаций.
- Frontend Architecture for Design Systems - связывает микрофронтенды с архитектурными стандартами команд: контрактами компонентов, и согласованностью UI.
- React.js: The Documentary - добавляет контекст экосистемы, в которой закрепились компонентная модель и многие практики независимой фронтенд-разработки.
- Vite: The Documentary - показывает, почему скорость локального цикла и современная сборка критичны для команд, выпускающих много независимых модулей.