Какие есть причины и критерии для разделения приложения на микрофронтенды?

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

Причины перехода

• Рост команды: когда над одним SPA работает 20+ разработчиков, релизы становятся узким местом.
• Независимый деплой: одна команда может выкатить фичу, не дожидаясь остальных.
• Разные технологии: старый Angular-модуль и новый React-модуль могут сосуществовать.
• Изоляция сбоев: падение одного микрофронтенда не обязательно ломает всё приложение.

Критерии для разделения

1. Есть чёткие бизнес-домены (каталог, корзина, профиль).
2. Команды автономны и владеют своими доменами end-to-end.
3. Требуется независимый релизный цикл.
4. Приложение уже большое и монолитный фронтенд тормозит разработку.

Пример с Module Federation

// host/webpack.config.js
new ModuleFederationPlugin({
  name: 'host',
  remotes: {
    catalog: 'catalog@https://cdn.example.com/remoteEntry.js'
  },
  shared: ['react', 'react-dom']
});

// В коде хоста
const Catalog = React.lazy(() => import('catalog/App'));

Здесь хост-приложение подгружает удалённый модуль каталога во время выполнения, а общие зависимости (React) шарятся, чтобы не дублировать их.

Когда не стоит

Если приложение небольшое, команда одна и релизы не конфликтуют, микрофронтенды принесут больше проблем: усложнится сборка, вырастет размер бандла, появятся проблемы с общим состоянием и стилями.

Итог: применять микрофронтенды стоит при масштабировании команд и необходимости независимых релизов по бизнес-доменам; в небольших проектах это избыточно.