Микрофронтенды

01Идея: делить по командам и бизнес-доменам

Представьте e-commerce сайт, который делают шесть команд: поиск, страницы товаров, checkout, аккаунт, контент и маркетинг. В единой фронтенд-кодовой базе каждое изменение проходит через одну сборку и один деплой, и баг в checkout может заблокировать релиз поиска. С микрофронтендами каждая команда владеет вертикальным срезом: своим репозиторием или пакетом, своим пайплайном и своим деплоем. Shell (его ещё называют host или container app) даёт каркас страницы, роутинг и общие сервисы и загружает нужный микрофронтенд для каждой области. Представьте торговый центр: одно здание, общие коридоры и охрана, но каждый магазин работает независимо. Ключевой принцип — делить по бизнес-возможностям, а не по техническим слоям вроде «команды хедера» и «команды кнопок».

• Shell / host: собирает страницу и владеет роутингом и глобальными задачами.
• Remote / микрофронтенд: независимо деплоящаяся часть UI.
• Контракт: согласованный интерфейс между shell и remote (props, события, роуты).

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

Композиция может происходить в разное время и в разных местах. Интеграция на этапе сборки публикует каждую часть как npm-пакет, который импортирует shell; это просто и быстро, но теряется независимый деплой, потому что shell нужно пересобирать. Серверная композиция сшивает HTML-фрагменты на сервере или edge (Edge Side Includes, сервис композиции или возможности фреймворков вроде Next.js Multi-Zones, где разные приложения владеют разными путями URL за одним доменом). Интеграция в рантайме загружает JavaScript от каждой команды в браузере: Module Federation, import maps с нативными ES-модулями или Web Components. Iframe дают самую сильную изоляцию, но плохую интеграцию с layout, роутингом и доступностью. Самый простой эффективный подход часто — разделение на уровне роутов: каждая команда владеет целыми страницами, а общей остаётся только навигация shell.

03Module Federation простыми словами

Module Federation, появившийся в webpack 5 и теперь доступный как самостоятельный рантайм (Module Federation 2.0) с плагинами для webpack, Rspack, Rsbuild и Vite, позволяет одной сборке загружать модули из другой сборки во время выполнения. Remote открывает модули (например, ./ProductPage) через небольшой entry-файл, который часто называется remoteEntry.js или описывается mf-manifest.json. Host объявляет remote и импортирует их модули так, будто они локальные; код загружается только при необходимости. Общие зависимости вроде React объявляются как синглтоны, чтобы страница загружала одну копию, а диапазоны версий согласуются в рантайме. Версия 2.0 добавляет протокол манифестов, подсказки типов для remote, систему runtime-плагинов и devtools.

1// rsbuild.config.ts (remote: product team)
2import { defineConfig } from "@rsbuild/core";
3import { pluginReact } from "@rsbuild/plugin-react";
4import { pluginModuleFederation } from "@module-federation/rsbuild-plugin";
5 
6export default defineConfig({
7  plugins: [
8    pluginReact(),
9    pluginModuleFederation({
10      name: "product",
11      exposes: { "./ProductPage": "./src/ProductPage.tsx" },
12      shared: {
13        react: { singleton: true, requiredVersion: "^19.0.0" },
14        "react-dom": { singleton: true, requiredVersion: "^19.0.0" },
15      },
16    }),
17  ],
18  server: { port: 3001 },
19});

04Подключение remote в shell

Host объявляет, где живёт каждый remote, и лениво загружает его модули. Оборачивайте каждый remote в error boundary и fallback на время загрузки: remote — это сетевая зависимость, которая может упасть или тормозить, и одна сломанная команда не должна ломать всю страницу. В продакшене URL remote должны браться из конфигурации или сервиса манифестов, а не быть зашиты в код, чтобы команды могли деплоить и откатываться без пересборки shell.

1// host: rsbuild.config.ts (excerpt)
2pluginModuleFederation({
3  name: "shell",
4  remotes: { product: "product@https://cdn.example.com/product/mf-manifest.json" },
5  shared: { react: { singleton: true }, "react-dom": { singleton: true } },
6});
7 
8// host: src/routes/ProductRoute.tsx
9import { lazy, Suspense } from "react";
10import { ErrorBoundary } from "react-error-boundary";
11 
12const ProductPage = lazy(() => import("product/ProductPage"));
13 
14export function ProductRoute() {
15  return (
16    <ErrorBoundary fallback={<p>Product details are unavailable right now.</p>}>
17      <Suspense fallback={<p>Loading…</p>}>
18        <ProductPage />
19      </Suspense>
20    </ErrorBoundary>
21  );
22}

05Взаимодействие и общее состояние

Микрофронтенды должны быть слабо связаны, поэтому они общаются через небольшие явные контракты, а не через общий глобальный стор. Распространённые варианты: URL и роутинг как основное состояние (ID товара живёт в URL), props, которые shell передаёт при монтировании remote, кастомные события браузера для уведомлений вроде «корзина обновлена» и бэкенд-API как источник истины, который каждая часть читает самостоятельно. Избегайте одного глобального Redux-стора, общего для всех команд: он воссоздаёт ту самую связанность, от которой вы уходили, разделяя приложение. Аутентификацией обычно владеет shell, который предоставляет функцию получения токена или контекст пользователя через крошечный общий интерфейс.

1// Contract: a typed custom event
2type CartUpdated = { count: number };
3 
4// Checkout micro-frontend
5window.dispatchEvent(new CustomEvent<CartUpdated>("cart:updated", { detail: { count: 3 } }));
6 
7// Shell header
8window.addEventListener("cart:updated", (e) => {
9  const { count } = (e as CustomEvent<CartUpdated>).detail;
10  renderBadge(count);
11});

06Дизайн-системы и единообразие

Самый заметный для пользователя риск — непоследовательный продукт: разные кнопки, отступы и поведение от каждой команды. Это решает общая дизайн-система: дизайн-токены (цвета, отступы, типографика как CSS-переменные), библиотека компонентов, опубликованная как версионированный пакет, и документация в Storybook. Команды используют её как любую другую зависимость. Важна и изоляция стилей: используйте CSS Modules, префикс для каждого микрофронтенда или Shadow DOM для Web Components, чтобы глобальный CSS одной команды не ломал страницу другой. Ломающие изменения в дизайн-системе должны быть редкими и анонсированными, потому что обновляться придётся каждой команде; токены в виде CSS-переменных позволяют менять темы в рантайме без передеплоя каждого remote.

07Монорепозиторий или полирепозиторий — и само решение

Микрофронтенды — про независимый деплой, а не обязательно про отдельные репозитории. Многие команды используют монорепозиторий (Nx, Turborepo, pnpm workspaces) с папкой на каждый микрофронтенд, отдельными пайплайнами сборки и деплоя, которые запускаются затронутыми изменениями, и общими инструментами. Так рефакторинг и обновление зависимостей остаются простыми, а владение командами сохраняется. Полирепозитории максимизируют автономию, но усложняют общие обновления и единообразие. Прежде чем выбирать, спросите, нужны ли вам микрофронтенды вообще: при менее чем трёх-четырёх фронтенд-командах хорошо структурированный модульный монолит с понятным владением папками, границами под контролем линтера и быстрым CI обычно даёт те же преимущества без сложности рантайма.

08Общие зависимости и согласование версий

Share scope в Module Federation — это реестр в рантайме, где каждая загруженная сборка регистрирует общие пакеты, которые она приносит, с их версиями. Когда модулю нужен React, рантайм выбирает версию, удовлетворяющую requiredVersion, предпочитая самую высокую из доступных, а singleton: true принудительно оставляет ровно один экземпляр, что требуется React, React DOM, роутерам и библиотекам на контексте, потому что две копии ломают хуки и контекст. Если совместимой версии нет, синглтон пишет предупреждение и всё равно использует загруженную, что может приводить к тонким багам; strictVersion превращает это в ошибку. eager: true включает общий модуль в начальный чанк, что убирает асинхронную границу, но увеличивает размер. Обычный паттерн — асинхронный bootstrap: entry-файл делает import('./bootstrap'), чтобы общие модули успели согласоваться до старта приложения.

1// src/index.ts  (entry)
2import("./bootstrap");
3 
4// src/bootstrap.tsx
5import { createRoot } from "react-dom/client";
6import { App } from "./App";
7createRoot(document.getElementById("root")!).render(<App />);
8 
9// shared config with strict checks for critical libs
10// shared: {
11//   react: { singleton: true, requiredVersion: "^19.0.0", strictVersion: true },
12//   "@acme/design-system": { singleton: true, requiredVersion: "^4.2.0" },
13// }

09Деплой, обнаружение и откаты

Для независимого деплоя shell нужен способ находить текущую версию каждого remote. Если зашить URL в сборку shell, деплои оказываются связанными. Лучше так: каждый remote публикует неизменяемые версионированные ресурсы (product/1.14.2/mf-manifest.json) в CDN, а небольшой discovery-документ или сервис сопоставляет имена remote с активной версией для каждого окружения. Shell читает его при старте, либо runtime-плагины Module Federation разрешают remote динамически. Откат означает перенаправить карту на предыдущую версию, ничего не пересобирая. Это также позволяет делать canary-релизы и переопределения для отдельных пользователей при тестировании. Кэшируйте discovery-документ ненадолго, а ресурсам давайте долгий срок кэширования, потому что их пути версионированы.

1// remotes.json served by a config endpoint (short cache)
2{
3  "product":  "https://cdn.example.com/product/1.14.2/mf-manifest.json",
4  "checkout": "https://cdn.example.com/checkout/3.2.0/mf-manifest.json"
5}
6 
7// shell bootstrap with the MF runtime
8import { init } from "@module-federation/enhanced/runtime";
9const remotes = await (await fetch("/config/remotes.json")).json();
10init({
11  name: "shell",
12  remotes: Object.entries(remotes).map(([name, entry]) => ({ name, entry: entry as string })),
13});

10Изоляция: CSS, глобальные объекты и сбои

Композиция в рантайме помещает код нескольких команд в один документ, поэтому изоляцию нужно проектировать. CSS: глобальные селекторы одного remote могут перестилизовать другой; используйте CSS Modules или scoped-стили фреймворка, добавляйте префикс ко всем глобальным классам и держите reset-стили только в shell. Web Components с Shadow DOM дают жёсткие границы стилей ценой более сложной темизации (используйте CSS custom properties, которые проходят сквозь shadow-границу). Глобальные объекты JavaScript: никогда не патчите window или прототипы в remote и добавляйте пространство имён к любым ключам хранилища. Сбои: error boundary на каждый remote, таймауты на загрузку remote и fallback UI сохраняют страницу рабочей. Помечайте ошибки и метрики производительности именем и версией remote, чтобы дежурные инженеры знали, какую команду поднимать.

11Серверная композиция и SSR

Federation на клиенте подходит для приложений за логином, но публичным страницам нужны быстрый first paint и SEO. Варианты: серверные приложения на уровне роутов за одним доменом (Next.js Multi-Zones или reverse proxy, направляющий /checkout в одно приложение, а /blog — в другое) — просто и надёжно, но между зонами происходит полная перезагрузка страницы; композиция HTML-фрагментов на edge или сервере, когда layout-сервис параллельно забирает фрагменты от каждой команды и стримит их; или federated SSR, когда Module Federation загружает remote-модули и на Node.js-сервере — мощно, но сложно в эксплуатации из-за серверного кэширования и памяти. Для большинства публичных сайтов прагматичный ответ — зоны на уровне роутов плюс общая дизайн-система и пакет хедера.

1# nginx: route-level composition under one domain
2location /checkout/ { proxy_pass http://127.0.0.1:3002; }
3location /account/  { proxy_pass http://127.0.0.1:3003; }
4location /          { proxy_pass http://127.0.0.1:3001; }  # main shop