Микрофронтенды это архитектурный подход при котором интерфейс большого веб приложения собирается из автономных фрагментов разрабатываемых и деплоимых отдельными командами. Каждый фрагмент живет своей жизнью со своим репозиторием своим пайплайном своим графиком релизов а оболочка приложения склеивает их в единое целое прямо в рантайме. Подход пришел во фронтенд из микросервисной архитектуры где крупные бекенды давно дробятся по доменам. Ниже разобраны сценарии где декомпозиция интерфейса оправдана подходы к интеграции и ловушки которые ждут команды на этом пути.
Проблема которую решает декомпозиция интерфейса на автономные части
Монолитный SPA по мере роста превращается в тормоз для всей организации. Сборка занимает десятки минут любая правка требует полного прогона регрессионных тестов а конфликты в общем коде вынуждают команды договариваться о каждом релизе. Одна сломанная фича блокирует деплой всего приложения потому что артефакт у проекта один и точка отказа одна.
Вторая проблема скорость доставки. Когда десятки разработчиков работают в одном коде мержи замедляются ревью растягиваются на дни а релизный поезд уходит строго по расписанию независимо от готовности конкретной фичи. Бизнес теряет гибкость а продукт страдает от очередей на публикацию даже когда сама фича готова и протестирована.
За техническими симптомами стоит организационная причина известная как закон Конвея структура системы повторяет структуру коммуникаций в компании. Пока все сидят в одном репозитории границы владения размываются код принадлежит всем и никому одновременно. Декомпозиция делает границы явными фрагмент каталога принадлежит команде каталога и это видно в структуре репозиториев пайплайнов и дашбордов мониторинга.
Декомпозиция решает эти проблемы через разграничение владения. Команда каталога деплоит когда готова и не координируется с командой оплаты кроме как через публичный контракт. Время выхода фичи перестает зависеть от размера организации и от чужих багов в общей кодовой базе.
Подходы к интеграции от iframe до сборки на стороне браузера
Исторически первым способом был iframe с отдельным документом на каждый фрагмент. Изоляция получается полная каждый iframe живет в собственном контексте но цена высока дублирование памяти медленная коммуникация через postMessage и плохая доступность для скринридеров которые видят набор разрозненных документов вместо целого приложения.
Следующий шаг веб компоненты. Custom elements с shadow DOM дают инкапсуляцию стилей и логики нативными средствами платформы без дополнительных абстракций:
class CartWidget extends HTMLElement {
connectedCallback() {
const root = this.attachShadow({ mode: 'open' });
root.innerHTML = '<button>Открыть корзину</button>';
root.querySelector('button').addEventListener('click', () => {
window.dispatchEvent(new CustomEvent('cart:open'));
});
}
}
customElements.define('cart-widget', CartWidget);Зрелым стандартом де факто стала сборка на стороне браузера через module federation появившийся в Webpack 5 и получивший аналоги в других сборщиках. Оболочка знает адреса фрагментов и подтягивает их код прямо в рантайме без iframe и без пересборки монолита при каждом изменении. Отдельного упоминания заслуживает single-spa оркестратор который управляет жизненным циклом фрагментов монтирует и размонтирует их при смене маршрута.
Альтернативный путь сборка на этапе билда когда фрагменты публикуются как npm пакеты а оболочка собирает их в один бандл. Подход проще в эксплуатации и не тащит рантаймовых сложностей но лишает команды независимых релизов любое изменение требует пересборки целого. Промежуточный вариант import maps стандарт который отображает спецификаторы модулей на URL и позволяет подменять версии фрагментов без пересборки оболочки конфигурацией на уровне браузера. Каждый уровень этой лестницы дает больше автономии за счет больше движущихся частей и выбирать точку на ней стоит по зрелости инфраструктурной команды и готовности платить сложностью за скорость.
Module Federation и общие зависимости между командами
Module Federation позволяет одному бандлу импортировать модули из другого в рантайме по сети. Фрагмент каталога объявляет что он отдает наружу а оболочка подключает это как обычный импорт.
Сторона фрагмента публикует манифест и экспортирует компоненты:
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'catalog',
filename: 'remoteEntry.js',
exposes: {
'./ProductList': './src/components/ProductList',
'./ProductCard': './src/components/ProductCard',
},
shared: {
react: { singleton: true },
'react-dom': { singleton: true },
},
}),
],
};Сторона оболочки подключает фрагмент по адресу манифеста:
new ModuleFederationPlugin({
name: 'shell',
remotes: {
catalog: 'catalog@https://cdn.example.com/catalog/remoteEntry.js',
checkout: 'checkout@https://cdn.example.com/checkout/remoteEntry.js',
},
shared: {
react: { singleton: true },
'react-dom': { singleton: true },
},
});Ключевой механизм shared. Без него каждый фрагмент притащил бы свою копию React и приложение получило бы конфликт контекстов состояния с классической ошибкой несовместимости хуков. Параметр singleton заставляет все фрагменты использовать одну копию библиотеки а загрузчик согласует совместимую версию в рантайме по semver диапазонам.
Версионирование манифеста требует отдельной дисциплины. Фрагмент публикуется в CDN по иммутабельным URL с хешем в имени а стабильный алиас указывает на актуальную версию. Тогда браузерный кеш работает корректно старые вкладки докачивают согласованное состояние а новые получают свежий код без рассинхрона зависимостей.
Контракт общих зависимостей это главный объект переговоров между командами. Версия фреймворка версия дизайн системы версия утилит фиксируются в соглашении и меняются медленно с уведомлением всех владельцев фрагментов за несколько спринтов до мажорного обновления.
Изоляция стилей и дизайн система в мире независимых модулей
Когда фрагменты пишутся разными командами стили неизбежно начинают конфликтовать. Класс с одинаковым именем в двух фрагментах глобальный селектор случайно вырвавшийся из модуля переопределение чужой кнопки через каскад все это ломает визуальную целостность приложения и рождает баги которые трудно воспроизвести.
Рабочие приемы изоляции проверены практикой. Shadow DOM для веб компонентов дает железную изоляцию. CSS modules хешируют имена классов на этапе сборки. Автоматические префиксы классов по имени фрагмента защищают от коллизий даже в легаси коде. Линтеры с правилами запрета глобальных селекторов закрывают вопрос на уровне ревью до того как код дойдет до продакшена.
Тематизация строится на CSS кастомных свойствах. Дизайн токены цвета отступы радиусы скруглений объявляются как переменные на уровне оболочки а фрагменты читают их в своих стилях. Это позволяет менять тему всего приложения не трогая код фрагментов и дает каждому домену точку настройки без правки чужих репозиториев.
Дизайн система при такой архитектуре обязана стать версионированным пакетом. Кнопки поля цвета токены живут в пакете который каждая команда обновляет по своему графику. Семантическое версионирование спасает от сюрпризов мажорная версия означает визуальные или поведенческие изменения которые команда тестирует до обновления а патчи применяются безбоязненно.
Маршрутизация и склейка приложения из отдельных фрагментов
Оболочка владеет верхним уровнем маршрутизации и решает какой фрагмент отвечает за адрес. Каталог слушает префикс /catalog корзина /cart оформление заказа /checkout аккаунт /account. Загрузка фрагмента происходит лениво по первому обращению к маршруту что экономит трафик на старте.
Правило хорошего тона маршруты принадлежат командам целиком. Команда владеет своим префиксом и всеми вложенными адресами а оболочка знает только верхний уровень. Это позволяет менять внутреннюю структуру маршрутов фрагмента не трогая общий конфиг и не согласовывая переименования с соседями.
Переходы между фрагментами строятся на событиях или общем событийном автобусе:
// фрагмент каталога инициирует переход к оформлению заказа
window.dispatchEvent(new CustomEvent('app:navigate', {
detail: { path: '/checkout?from=catalog', items: ['sku-42'] },
}));Оболочка слушает событие и передает управление фрагменту оформления передавая полезную нагрузку через публичный контракт. Команды остаются развязанными каталог не знает внутренностей оформления а только формат события перехода.
Отказоустойчивость склейки держится на границах ошибок. Если фрагмент каталога упал или его CDN недоступен оболочка показывает заглушку на своем месте а остальное приложение продолжает работать. Ошибка границы фрагмента не должна ронять весь интерфейс в этом и состоит смысл автономии.
Когда микрофронтенды вредят а не помогают проекту
Декомпозиция интерфейса не универсальное лекарство. Для команды из пяти человек и одного продукта накладные расходы съедят всю выгоду. Несколько пайплайнов несколько окружений договорные процессы по общим библиотекам все это стоит времени и внимания которых в маленькой команде просто нет.
Бандл растет. Без дисциплины shared каждый фрагмент тащит свои копии библиотек и пользователь скачивает одно и то же по три раза на первой загрузке. Отладка усложняется стек трейсы пересекают границы фрагментов а сеть добавляет задержку при первом обращении к удаленному коду что бьет по метрике времени до интерактивности.
Тестирование тоже дорожает. Модульные тесты остаются внутри команд а вот интеграционные требуют стенда с собранным приложением из актуальных версий всех фрагментов. Контрактные тесты проверяющие соответствие манифеста ожиданиям оболочки смягчают проблему но не отменяют необходимость сквозных проверок перед крупными изменениями общих библиотек.
Дисциплина контрактов требует зрелости организации. Если команды не умеют договариваться о версиях границах и сроках микросервисная архитектура не спасет а усилит хаос превратив монолит в неуправляемое облако фрагментов. Правило простое микрофронтенды решают организационные проблемы и оправданы только при организационной сложности соответствующего масштаба.
Практики внедрения от первого модуля до полной декомпозиции
Здоровый путь это постепенное выделение фрагментов начиная с одного домена с четкой границей и минимальными связями с остальным кодом. Последовательность шагов выглядит так:
- Выделить один домен с минимальными зависимостями и собрать его как автономный фрагмент;
- Настроить оболочку и контракт общих библиотек с singleton для фреймворка и его экосистемы;
- Вынести дизайн систему в версионированный пакет с семантическим версионированием;
- Закрепить владение маршрутами и событийные контракты переходов между фрагментами;
- Замерить метрики сборки размера бандла и времени до интерактивности до и после перехода.
Наблюдаемость становится частью контракта с первого дня. Каждый фрагмент пишет метрики загрузки ошибок и производительности в общий мониторинг с тегом владельца тогда дежурный видит какой домен просел и кому адресовать инцидент без общего разбора.
Дальше действует правило одного фрагмента за квартал. Каждое выделение это эксперимент который приносит уроки о границах контрактах и инфраструктуре. Через год такой ритм превращает монолит в конфедерацию автономных модулей где каждая команда двигается со своей скоростью релизный поезд отменяется а деплой перестает быть событием требующим общего сбора.