СправочникОбновлено · 09.2026

Микрофронтенд: как фронтенд, но поменьше

28 июля 2023 · 17 минут чтения

Проверка фактов

Юлия Найпак

Методист по автоматизации. Сверяет паспорт инструмента с документацией вендора.

Автор Р

Редакция

Коллектив авторов, редакторов и иллюстраторов статей на сайте блога онлайн-университета «Зерокодер». Пишем…

Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.

Микрофронтенд (microfrontend) — это способ собрать интерфейс одного веб-приложения из нескольких независимых фронтенд-приложений: каждое пишет своя команда, на своём стеке, и выкатывает отдельно от остальных. Подход переносит логику микросервисов с бэкенда на клиентскую часть.

• Термин появился в отчёте ThoughtWorks Technology Radar в конце 2016 года — так пишет Михаэль Геерс на micro-frontends.org.
• Собрать микрофронтенды можно пятью способами: сборка на сервере, сборка на этапе билда, iframe, композиция в рантайме через JavaScript и Web Components.
• Рабочий стандарт рантайм-сборки сегодня — Module Federation. С апреля 2024 года это самостоятельный проект с собственным рантаймом; версия внутри Webpack 5 стала лишь его частным случаем.
• Главная цена подхода — вес страницы: независимые сборки дублируют общие библиотеки, и пользователь качает React столько раз, сколько у вас микрофронтендов.
• Порог окупаемости — организационный. Одной небольшой команде микрофронтенды дают минус в скорости; нескольким командам с разными релизными циклами — плюс.

Что такое микрофронтенд простыми словами

Обычное большое веб-приложение живёт в одной кодовой базе: один репозиторий, одна сборка, один деплой. Пока над ним работают три человека, это удобно. Когда людей становится сорок, любая правка в корзине требует пересборки всего каталога, а релиз ждёт, пока десять команд закончат свои задачи. Такую кодовую базу на micro-frontends.org называют фронтенд-монолитом.

Микрофронтенд разрезает этот монолит по бизнес-доменам. Каталог товаров, корзина, личный кабинет и оплата становятся отдельными приложениями со своим репозиторием, своей сборкой и своим пайплайном выкатки. На странице их собирает приложение-оболочка (shell, или контейнер): оно рисует общие элементы вроде шапки и подвала, разбирается с авторизацией и навигацией и говорит каждому микрофронтенду, когда и в какой узел DOM ему отрисоваться.

Отсюда сразу видно, чем микрофронтенд отличается от обычного компонента. Компонент — это единица переиспользования кода внутри одной сборки; микрофронтенд — единица владения и выкатки. Компонент выкатывается вместе со всем приложением, микрофронтенд — сам по себе. Формулировка Кэма Джексона из Thoughtworks в статье на martinfowler.com звучит так: наш выбор технологий, кодовые базы, команды и релизные процессы должны уметь работать и развиваться независимо друг от друга, без избыточной координации.

Пишут это слово по-разному: микрофронтенд, микро фронтенд, английское microfrontends и micro frontends в два слова, как у Thoughtworks. Речь везде об одном и том же.

Особенности и принципы микрофронтендов

Разделение по функциональности. Каждый микрофронтенд — независимый модуль с определённой функциональностью, который разрабатывают и разворачивают отдельно. Границу режут по бизнес-домену: «оформление заказа» — это микрофронтенд, «все формы приложения» — нарезка по слоям, которую трогает каждая задача. Команда отвечает за домен целиком, от базы до кнопки.

Независимость технологий. Модули могут использовать разные библиотеки и фреймворки в зависимости от требований. Привязка к одному общему стеку исчезает, и легаси на AngularJS живёт рядом с новым модулем на React, пока его переписывают. Именно из этой боли вырос single-spa: по документации проекта, фреймворк родился из желания команды Canopy использовать React с react-router вместо того, чтобы навсегда остаться с приложением на AngularJS и ui-router.

Самодостаточность. Модули разворачиваются, масштабируются и обслуживаются независимо друг от друга. Каждый представляет собой законченный автономный кусок веб-интерфейса, что упрощает управление проектом и распределение обязанностей в команде разработчиков. Практическое следствие: у каждого микрофронтенда свой CI/CD и свой адрес, по которому лежит его сборка.

Инкрементное внедрение. Подход позволяет постепенно переходить от монолитной архитектуры к распределённой, добавляя новые микрофронтенды по одному. Это упрощает миграцию и снижает риски: старый монолит остаётся оболочкой, а вынесенные куски подключаются к нему по мере готовности.

Гибкость и масштабируемость. Новые функции выкатываются без пересборки остальных частей системы. Ошибка в одном модуле не обязана ронять всю страницу — оболочка оборачивает загрузку микрофронтенда в обработчик и показывает заглушку вместо белого экрана.

Четыре принципа из пяти описывают организацию работы, и только один — код. Микрофронтенд остаётся архитектурным ответом на структуру команд, поэтому решение о нём принимают вместе с тимлидами.

Зачем использовать микрофронтенд

Улучшенная командная работа. Сложный проект разбивается на мелкие понятные зоны ответственности, каждая закреплена за командой. Пропадает очередь на ревью в общем репозитории и споры о том, чей коммит сломал сборку.

Быстрая разработка и развёртывание. За счёт независимости выкатка новой функции перестаёт зависеть от чужого расписания. Команда каталога релизится в среду, команда оплаты — в пятницу, координировать нечего.

Лёгкость обновлений. Обновить один компонент можно без остановки всего приложения и без влияния на остальные части. Это же свойство даёт путь для миграции: старый фреймворк меняют по одному модулю за раз, вместо большого переписывания.

Улучшенное масштабирование. Речь о масштабировании разработки. Добавить в проект ещё одну команду проще, чем ещё десять человек в существующую: новой команде выделяют домен, репозиторий и пайплайн вместо места в общем календаре релизов.

Отдельная выгода — устойчивость. В монолите падение одного участка часто уносит весь бандл. В распределённом интерфейсе оболочка ловит ошибку загрузки конкретного модуля и продолжает работать без него.

Если фронтенд у вас пишет один человек или маленькая команда, эти выгоды не появятся: платить за них придётся инфраструктурой, а получить нечего. Как ускорить работу небольшой командой, мы разбирали в материале как универсальный разработчик с 20-летним опытом увеличил скорость разработки в 3 раза с помощью ИИ, а прикладные приёмы для фронтендера собраны в подборке 5 промптов ChatGPT для фронтенд-разработчика.

Пять способов собрать микрофронтенд

Канонический список подходов дал Кэм Джексон в статье о микрофронтендах на martinfowler.com: композиция серверных шаблонов, интеграция на этапе сборки, рантайм-интеграция через iframe, рантайм-интеграция через JavaScript и рантайм-интеграция через Web Components.

Композиция на сервере. Страницу склеивает веб-сервер: общий index.html содержит разметку-каркас, а куски подставляются server-side includes. В примере Джексона это делает Nginx с директивой ssi on, подставляя нужный HTML-фрагмент по URL. На micro-frontends.org этот вариант называют удачным для проектов ближе к «документам»: страница приходит готовой, интерактивность добирают отдельно.

Интеграция на этапе сборки. Каждый микрофронтенд публикуется npm-пакетом, контейнер подключает их как обычные зависимости. Выглядит логично и позволяет дедуплицировать общие библиотеки. Джексон рекомендует этого избегать: чтобы выпустить изменение в одной части продукта, придётся пересобрать и выпустить все микрофронтенды разом — тот самый lockstep-релиз, ради ухода от которого архитектуру и затевали.

iframe. Самый простой способ сложить приложения в браузере. Даёт хорошую степень изоляции стилей и глобальных переменных практически даром. Плата описана там же: изоляция делает iframe менее гибким, усложняет маршрутизацию, историю переходов и глубокие ссылки и добавляет проблем с адаптивной вёрсткой.

Рантайм-интеграция через JavaScript. Оболочка подгружает скрипт микрофронтенда тегом script и вызывает у него функцию монтирования, передав нужный узел DOM. Самый гибкий вариант: модуль решает, когда рисоваться, и умеет общаться с оболочкой. На этом принципе работают single-spa и Module Federation.

Web Components. Тот же рантайм, но модуль публикует себя как кастомный элемент, и оболочка ставит на страницу тег вроде <order-food>. Плюс — нативный браузерный контракт и Shadow DOM для изоляции стилей; на micro-frontends.org кастомные элементы называют хорошим способом спрятать детали реализации команды. Плата — командам придётся заранее договориться о наборе атрибутов и событий каждого элемента.

Сравнение способов реализации микрофронтенда

Строка «общие зависимости» в этой таблице — самая дорогая. Кэм Джексон формулирует проблему прямо: независимо собранные JavaScript-бандлы дублируют общие зависимости и увеличивают число байт, которые прилетают пользователю. Если каждый микрофронтенд везёт свою копию React, клиент скачает React n раз. Дальше он же отмечает встроенное противоречие: как только общие зависимости выносят наружу, между микрофронтендами возвращается неявный контракт «все обязаны использовать вот эти версии вот этих библиотек», а вместе с ним — согласованные обновления, ради ухода от которых всё и начиналось.

Берите самый дешёвый способ из тех, что закрывают вашу задачу. Изоляция чужого кода — iframe. Разные фреймворки в одном экране — Web Components. Одна большая SPA и несколько команд — рантайм через JavaScript, и дальше почти всегда Module Federation.

Module Federation: как он работает и что изменилось в версии 2.0

Module Federation появился как возможность Webpack 5. Формулировка мотивации в документации Webpack: несколько раздельных сборок должны образовывать одно приложение; эти сборки ведут себя как контейнеры и могут отдавать и потреблять код друг друга. Там же вводится ключевое различие: локальные модули — обычные модули текущей сборки, удалённые (remote) модули не входят в сборку и подгружаются в рантайме из удалённого контейнера.

На практике это три настройки в конфиге. Remote объявляет, что отдаёт наружу, host объявляет, откуда берёт, и обе стороны договариваются о разделяемых библиотеках:

// remote: catalog/webpack.config.js
new ModuleFederationPlugin({
  name: "catalog",
  filename: "remoteEntry.js",
  exposes: { "./ProductList": "./src/ProductList" },
  shared: { react: { singleton: true }, "react-dom": { singleton: true } },
});

// host: shell/webpack.config.js
new ModuleFederationPlugin({
  name: "shell",
  remotes: { catalog: "catalog@https://catalog.example.com/remoteEntry.js" },
  shared: { react: { singleton: true }, "react-dom": { singleton: true } },
});

Дальше host импортирует чужой модуль так же, как свой: import("catalog/ProductList"). Схема пути модуля от remote к host — ниже по тексту.

Теперь важное для тех, кто читал про микрофронтенды пару лет назад. 26 апреля 2024 года команда Web Infra в ByteDance вместе с автором Module Federation Заком Джексоном объявила официальный релиз Module Federation 2.0. Это уже не только плагин внутри сборщика: по официальной документации проекта, версия 2.0 отличается от встроенной в Webpack 5 тем, что добавляет к базовым возможностям экспорта, загрузки и разделения зависимостей динамические подсказки типов, Manifest, Federation Runtime и систему рантайм-плагинов.

Что из этого меняет работу:

• Рантайм отвязан от сборщика. Возможности, зашитые раньше в Webpack, вынесены в отдельный SDK: регистрировать и грузить удалённые и разделяемые модули можно динамически, без привязки к инструменту сборки.
• Типы приезжают вместе с модулем. Плагин сборки автоматически генерирует и подгружает типы для TypeScript-проектов и синхронизирует их в режиме разработки.
• Манифест mf-manifest.json. Отдельный файловый протокол, который упрощает интеграцию с платформами деплоя и управление версиями ресурсов.
• Rspack наравне с Webpack. В списке возможностей на официальном сайте прямо указана поддержка обоих сборщиков; в анонсе 2.0 сказано, что совместимы Webpack и Rspack, а другие сборщики могут реализовать стандарт у себя.

Если в вашей статье-источнике Module Federation описан как «фича Webpack 5», источник устарел на два года. Собственный рантайм и манифест — та часть, ради которой в 2026 году стоит открывать официальную документацию проекта вместо пересказов.

Как использовать микрофронтенд: порядок внедрения

Шаг 1. Разделение функциональности. Определите функциональные области приложения, которые можно вынести в отдельные микрофронтенды: панель администратора, страница каталога, корзина. Проверка границы простая — если у куска есть свой владелец на стороне бизнеса и свой набор метрик, граница проведена верно.

Шаг 2. Выбор технологий. Каждый модуль может использовать свой стек. Подберите инструменты под задачу модуля, но заранее зафиксируйте общий список: какие библиотеки объявляются в shared, какая версия считается основной и кто её обновляет.

Шаг 3. Определение интерфейсов. Опишите, как модули общаются между собой. Рабочих вариантов три: пропсы и колбэки, которые оболочка передаёт при монтировании; браузерные события; URL как единственный источник правды о состоянии. Общий стор между микрофронтендами связывает их обратно в монолит, поэтому его берут последним.

Шаг 4. Разработка и развёртывание. Каждый микрофронтенд собирается и выкатывается независимо, у него свой пайплайн и свой адрес сборки. В сценарии из документации Webpack каждая страница SPA выносится отдельной сборкой-контейнером, а оболочка ссылается на все страницы как на удалённые модули и переезжает только при изменении маршрутов.

Шаг 5. Тестирование и мониторинг. Модуль тестируют изолированно и в составе оболочки. Мониторинг обязателен на уровне загрузки: падение remoteEntry.js одного модуля должно быть видно в логах раньше, чем о нём напишет пользователь.

Отдельно про инструмент, если стек разнородный. single-spa, по документации версии 6.x, — фреймворк, который сводит несколько JavaScript-микрофронтендов в одно приложение и позволяет держать React, AngularJS, Angular и Ember на одной странице без перезагрузки. Каждое приложение регистрируется тремя вещами: именем, функцией загрузки кода и функцией, определяющей, когда приложение активно; само приложение обязано уметь bootstrap, mount и unmount себя из DOM.

Что ломается при внедрении микрофронтендов

Первая неделя на Module Federation обычно уходит на три конкретные ошибки. Все они описаны в разделе Troubleshooting официальной документации Webpack, там же лежат способы починки.

Uncaught Error: Shared module is not available for eager consumption. Приложение синхронно выполняет то, что обязано грузиться асинхронно. Документация предлагает два выхода и рекомендует первый: вынести инициализацию за асинхронную границу. Содержимое точки входа переносят в файл bootstrap.js, а в index.js остаётся одна строка import('./bootstrap'). Второй вариант — пометить зависимость как eager: true в shared, но тогда все предоставленные и резервные модули будут скачиваться всегда, поэтому делать так рекомендуют в одной точке приложения, например в оболочке.

Uncaught Error: Module «./Button» does not exist in container. Имя в exposes записано без ведущего ./. Правильная форма — './Button': './src/Button'. Ошибка типична при переезде со старых бета-версий Webpack 5.

Тихая коллизия output.uniqueName. Самая неприятная из трёх, потому что молчит. В связке Module Federation у host и у каждого remote значение output.uniqueName обязано быть глобально уникальным. Webpack по умолчанию берёт его из поля name в package.json — значит две сборки с одинаковым именем пакета (обычное дело, когда remote выделяют из существующего проекта) могут молча столкнуться в рантайме. Лечение — задать output.uniqueName явно в каждом конфиге либо развести проекты по разным package.json.

Вес страницы. Здесь ломается уже сама архитектура, и конфигом это лечится лишь частично. Кэм Джексон отмечает: связь между скоростью страницы и вовлечённостью пользователя прямая, а значительная часть мира сидит на интернете гораздо медленнее, чем в развитых городах, поэтому размер загрузки важен. Он же добавляет утешение: даже если ничего не делать с дублями, отдельная страница может грузиться быстрее, чем в монолите — раздельная сборка работает как самодельный code splitting, и при заходе качается код только этой страницы. Расплата приходит на переходах: пользователь заново качает те же зависимости.

Три ошибки конфига закрываются по документации за один заход. Вес страницы придётся мерить и держать под контролем весь срок жизни архитектуры.

Когда микрофронтенд не окупается

Порог входа в микрофронтенды организационный, поэтому и считать надо в командах и релизных циклах.

• Одна небольшая команда. Операционная сложность распределённого интерфейса — отдельные пайплайны, версии общих библиотек, сквозной мониторинг — съедает всю выгоду. Монолит с хорошей модульностью здесь быстрее.
• Общий релизный цикл. Если все команды всё равно выкатываются одним общим поездом, независимый деплой никому не пригодится. Главный выигрыш микрофронтенда останется неиспользованным.
• Жёсткие требования к скорости первой отрисовки. Дублирование зависимостей и дополнительные запросы за remoteEntry.js добавляют вес и задержку. Лендинг или витрина, где важна каждая доля секунды при первой загрузке, дешевле собираются целиком.
• Нарезка по слоям. «Микрофронтенд для всех форм» или «микрофронтенд для всех таблиц» даёт связность вместо независимости: любая задача трогает несколько модулей сразу.

Работает подход в обратной ситуации: несколько продуктовых команд, разные релизные циклы, легаси-фреймворк, который надо снимать по кускам, или экраны с принципиально разными требованиями к стеку. Именно ради последнего сценария Module Federation в официальной документации называют подходящим для больших приложений, микрофронтендной архитектуры и разработки несколькими командами.

Промежуточный вариант, который часто пропускают: модульный монолит. Один репозиторий и одна сборка, но жёсткие границы модулей, запрет на импорт через границу и владелец у каждого модуля. Он даёт большую часть организационной пользы без инфраструктурного счёта, и переход на него обходится заметно дешевле. Микрофронтенды имеет смысл включать, когда модульный монолит уже упёрся в общий деплой.

Пример использования микрофронтенда

Допустим, у вас сложное веб-приложение для электронной коммерции: каталог товаров, корзина, профили пользователей и система оплаты. Вы переходите на микрофронтенд-архитектуру, чтобы повысить гибкость и ускорить разработку. Функциональность делится на четыре микрофронтенда:

1. Каталог товаров — отображение списка, фильтрация и сортировка. Отдаёт наружу ./ProductList и ./ProductCard.
2. Корзина — добавление товаров и оформление заказа. Слушает событие cart:add, которое бросает каталог.
3. Профили пользователей — персональная информация и история заказов. Данные о текущем пользователе получает пропсом от оболочки, чтобы не дублировать запрос авторизации.
4. Система оплаты — обработка платежей. Живёт на отдельном домене под своими требованиями безопасности, оболочка подключает его последним и с обработчиком ошибок.

Оболочка держит шапку, подвал, роутинг верхнего уровня и авторизацию. Общими объявляются React, react-dom и пакет дизайн-системы: их прописывают в shared с флагом singleton: true, чтобы на странице жила одна копия. Каждый из четырёх модулей выкатывается своим пайплайном, оболочка переезжает только при добавлении маршрутов.

Первым выносят тот модуль, у которого меньше всего связей с остальными. В магазине это обычно личный кабинет: он редко меняется вместе с каталогом и почти не делит с ним состояние. Каталог и корзина связаны сильнее всего, поэтому их разделяют последними и уже с продуманным контрактом событий.

Частые вопросы про микрофронтенды

Чем микрофронтенд отличается от компонента?

Компонент — единица переиспользования кода внутри одной сборки, он выкатывается вместе со всем приложением. Микрофронтенд — единица владения и выкатки: у него свой репозиторий, своя сборка и свой пайплайн, и его релиз не зависит от релиза соседей.

Можно ли использовать разные фреймворки в одном приложении?

Да, это одна из причин выбирать микрофронтенды. По документации single-spa версии 6.x, фреймворк позволяет держать на одной странице React, AngularJS, Angular и Ember без перезагрузки страницы. Плата — вес: каждый фреймворк приезжает в браузер отдельно.

Module Federation — это то же самое, что микрофронтенды?

Нет. Микрофронтенды — архитектурный подход, Module Federation — один из инструментов его реализации. В документации Webpack прямо сказано, что этот механизм часто называют микрофронтендами, но он ими не ограничивается: тем же способом шарят код между обычными приложениями.

Что изменилось в Module Federation 2.0?

Официальный релиз состоялся 26 апреля 2024 года. По документации проекта, версия 2.0 отличается от встроенной в Webpack 5 тем, что кроме экспорта, загрузки и разделения зависимостей даёт динамические подсказки типов, Manifest, Federation Runtime и систему рантайм-плагинов. Рантайм вынесен из сборщика в отдельный SDK, поддерживаются Webpack и Rspack.

Как микрофронтенды влияют на скорость загрузки?

Независимо собранные бандлы дублируют общие зависимости: если каждый микрофронтенд везёт свою копию React, пользователь скачает React столько раз, сколько модулей на странице. Часть веса снимает объявление библиотек в shared. При этом первая загрузка конкретной страницы может оказаться быстрее, чем в монолите, потому что раздельная сборка работает как code splitting; медленнее становятся последующие переходы.

С какого модуля начинать переход с монолита?

С того, у которого меньше всего связей с остальным приложением и есть отдельный владелец на стороне бизнеса. Личный кабинет или админ-панель подходят лучше, чем каталог, плотно связанный с корзиной.

Нужны ли микрофронтенды небольшой команде?

Как правило, нет. Отдельные пайплайны, согласование версий общих библиотек и сквозной мониторинг стоят времени, а выигрыш от независимого деплоя появляется только при нескольких командах с разными релизными циклами. Промежуточный вариант — модульный монолит с жёсткими границами модулей.

Заключение

Микрофронтенд меняет не столько код, сколько способ работы над продуктом: интерфейс делится на автономные приложения, каждое со своей командой, сборкой и выкаткой. Подход даёт независимый деплой, свободу стека и постепенную миграцию с монолита, а взамен берёт вес страницы и операционную сложность. Считать выгоду стоит в командах и релизных циклах, выбирать способ сборки — по таблице выше, а конфиг Module Federation сверять с официальной документацией: с апреля 2024 года он живёт отдельным проектом со своим рантаймом и манифестом.

Тем, кто выбирает направление внутри разработки, пригодится обзор востребованных профессий в IT-сфере в 2025–2028, а ускорить рутину по коду помогают приёмы из гайда как кодить с GPT-5.