Как настраивается Micro Frontend?

Настройка Micro Frontends: Комплексное руководство

Настройка Micro Frontends (MFE) — это многоуровневый процесс, который затрагивает архитектуру, инструментарий, коммуникацию и DevOps. В отличие от монолита, здесь мы имеем дело с независимыми, самодостаточными приложениями (микрофронтами), которые интегрируются в единую оболочку (shell/host application). Вот ключевые аспекты настройки.

1. Выбор архитектурного подхода

Первый и главный шаг — определиться со стратегией интеграции микрофронтов. Существует три основных паттерна:

• Компиляция во время сборки (Build-time integration): Микрофронты публикуются как пакеты (например, npm), и shell-приложение включает их как зависимости. Обновление требует пересборки и деплоя shell.

  // package.json shell-приложения
  {
    "dependencies": {
      "microfrontend-auth": "1.2.0",
      "microfrontend-dashboard": "2.1.0"
    }
  }
  

    **Плюсы:** Простота, нет проблем с изоляцией. **Минусы:** Отсутствие независимого деплоя, тесная связь версий.

• Интеграция на стороне клиента (Client-side integration): Наиболее популярный подход. Shell-приложение динамически загружает бандлы микрофронтов во время выполнения (runtime). Часто используется Webpack Module Federation или система импорта карт (import maps).

  // Пример динамической загрузки (без Module Federation)
  const loadMicroFrontend = async (name, path) => {
    await loadScript(`${path}/vendor.js`);
    await loadScript(`${path}/main.js`);
    window[name].mount(document.getElementById('container'));
  };
  

• Интеграция на стороне сервера (Server-side integration): Shell-приложение (SSR) собирает HTML-фрагменты от различных сервисов микрофронтов (например, через Edge Side Includes или с помощью специального компоновщика). Плюсы: Лучшая SEO и первая загрузка. Минусы: Сложность выше.

2. Настройка Module Federation в Webpack

Для клиентской интеграции Webpack Module Federation стал стандартом де-факто. Настройка происходит в webpack.config.js как для remote (микрофронт), так и для host (оболочка) приложений.

// webpack.config.js микрофронта (remote)
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'dashboard', // Уникальное имя
      filename: 'remoteEntry.js', // Точка входа для загрузки
      exposes: { // Какие модули "экспортируем"
        './DashboardApp': './src/bootstrap',
      },
      shared: { // Общие зависимости
        react: { singleton: true, eager: true },
        'react-dom': { singleton: true, eager: true },
      },
    }),
  ],
};

// webpack.config.js shell-приложения (host)
new ModuleFederationPlugin({
  name: 'shell',
  remotes: { // Откуда загружаем микрофронты
    dashboard: 'dashboard@http://localhost:3001/remoteEntry.js',
    auth: 'auth@http://localhost:3002/remoteEntry.js',
  },
  shared: {
    react: { singleton: true, eager: true },
    'react-dom': { singleton: true, eager: true },
  },
});

3. Организация проекта и изоляция

Каждый микрофронт должен быть полностью независимым проектом со своим репозиторием (или монорепозиторием), процессом CI/CD и возможностью деплоя. Критически важна изоляция:

• Стили: Используйте CSS-in-JS (Styled-components, Emotion), CSS Modules или тщательный нейминг по методологии (например, BEM) для предотвращения коллизий.
• Состояние: Глобальное состояние (например, авторизация) выносится в общую библиотеку или передается через Custom Events, Context API (в React) или паттерн публикатор-подписчик. Избегайте прямого обращения к глобальному объекту другого микрофронта.
• DOM: Каждый микрофронт должен работать в своем выделенном DOM-элементе (контейнере). Методы mount и unmount — обязательны для управления жизненным циклом.

4. Маршрутизация (Routing)

Маршрутизация — одна из самых сложных задач. Есть два подхода:

• Централизованная (в shell): Shell-приложение содержит главный роутер и отображает микрофронты на основе пути (/dashboard/*, /settings/*).
• Децентрализованная: Каждый микрофронт управляет своим поддеревом маршрутов. Для связи между ними используется библиотека вроде single-spa или qiankun, которые координируют загрузку и выгрузку приложений на основе URL.

5. DevOps и CI/CD конвейер

Независимый деплой — сердце MFE. Настройте CI/CD так, чтобы:

1. Каждый микрофронт собирался и тестировался отдельно.
2. Артефакты (бандлы, remoteEntry.js) деплоились на CDN или отдельный хост.
3. Shell-приложение, ссылаясь на конкретные версии или latest-теги, могло загружать их без пересборки. Используйте семантическое версионирование и стратегии постепенного развертывания (canary-релизы).

6. Межприложная коммуникация

Сведите коммуникацию к минимуму. Используйте простые, слабосвязанные методы:

• Custom Events: для широковещательных сообщений (например, userLoggedIn).

  // В микрофронте Auth
  window.dispatchEvent(new CustomEvent('auth:login', { detail: user }));
  
  // В микрофронте Dashboard
  window.addEventListener('auth:login', (event) => updateUI(event.detail));
  

• Параметры URL и Query String: для передачи простого контекста.
• Общий Singleton или Context: только для действительно глобальных данных, таких как тема или токен пользователя.

Ключевые инструменты и библиотеки

• Бандлинг/Интеграция: Webpack Module Federation, Vite, SystemJS (с import maps).
• Фреймворки-интеграторы: single-spa, qiankun, Piral, Luigi.
• Монорепозитории (опционально): Nx, Lerna, Turborepo — упрощают управление множеством пакетов в одном репозитории.
• Тестирование: Cypress для E2E-тестов всей сборки, Jest/React Testing Library для unit-тестов внутри каждого микрофронта.

Итог: Настройка Micro Frontends требует тщательного планирования. Начните с малого, выбрав один подход (рекомендуется Module Federation), обеспечьте строгую изоляцию и настройте независимые пайплайны деплоя. Это компромисс: вы получаете независимость команд и гибкость, но усложняете инфраструктуру и первоначальную настройку. Успех внедрения на 80% зависит от организационных соглашений между командами, а не от технологий.