Микрофронтенды: когда имеет смысл делить фронтенд
Продвинутое3 минРедакция Innovialabs
Коротко
Микрофронтенды делят один интерфейс на части, которые разные команды разрабатывают и выкатывают независимо; они решают организационную проблему и почти всегда избыточны для одной небольшой команды.
Коротко: что это и зачем
Микрофронтенды — это подход, при котором один веб-интерфейс собирается из нескольких независимых приложений. Например, каталог, корзина и личный кабинет разрабатываются разными командами, живут в разных репозиториях и выкатываются отдельно, а пользователь видит единый сайт.
Главное: микрофронтенды решают организационную задачу, а не техническую. Они нужны, когда несколько команд мешают друг другу в одном фронтенде: ждут общих релизов, конфликтуют в коде, не могут обновить зависимости. Если такой проблемы нет, подход добавит сложности без пользы.
Способы интеграции
Собрать части в одно целое можно по-разному:
| Подход | Как работает | Плюсы | Минусы |
|---|---|---|---|
| Module Federation | Сборщик позволяет одному приложению загружать модули другого во время выполнения | Независимый деплой, общие зависимости грузятся один раз | Привязка к сборщику, сложная отладка версий |
| Интеграция на сервере / edge | Сервер склеивает HTML из фрагментов разных сервисов | Быстрый первый рендер, хорошо для SEO | Сложнее интерактивность и общее состояние |
| Сборка через пакеты | Каждая часть публикуется как npm-пакет, хост собирает их вместе | Просто, типизировано | Нет независимого деплоя: любое изменение требует пересборки хоста |
| iframe | Каждая часть открывается во фрейме | Полная изоляция | Проблемы с UX, адаптивностью, навигацией и SEO |
| Web Components | Части оформлены как кастомные элементы | Не зависит от фреймворка | Нужно самим решать загрузку, версии и общее состояние |
| Роутинг по путям | Разные URL обслуживают разные приложения | Самый простой вариант | Переход между частями — полная перезагрузка страницы |
Часто самый практичный старт — разделение по путям: /shop — одно приложение, /account — другое, общий только дизайн-пакет.
Что вы получаете
- Независимые релизы: команда корзины выкатывается, не дожидаясь команды каталога.
- Четкие границы ответственности: у каждой части есть владелец.
- Постепенная миграция: старый интерфейс можно переписывать по кускам, не останавливая продукт.
- Свобода в технологиях — в теории. На практике смешение фреймворков обычно приносит больше проблем, чем пользы.
Чем вы платите
- Производительность. Риск загрузить несколько копий фреймворка и библиотек, больше JavaScript и сетевых запросов. Общие зависимости нужно настраивать явно.
- Согласованность UI. Без общей дизайн-системы кнопки и отступы начинают расходиться между частями.
- Общее состояние. Авторизация, корзина, язык интерфейса — все это нужно синхронизировать через контракты: события, URL, общее хранилище.
- Инфраструктура. Несколько пайплайнов, версионирование контрактов, мониторинг ошибок по частям, сквозные тесты.
- Отладка. Ошибка может возникнуть на стыке двух независимо выкаченных частей.
Признаки, что микрофронтенды вам не нужны
- Над фронтендом работает одна команда или несколько человек.
- Релизы не блокируют друг друга, конфликты в коде редки.
- Проблема на самом деле в плохой структуре кода — ее решают модули, границы внутри монорепозитория и code review.
- Хочется «попробовать разные фреймворки».
- Продукт еще ищет свою форму, и границы между частями будут часто меняться.
Хорошая альтернатива — модульный монолит: одно приложение, но с четкими границами доменов, отдельными папками и правилами импорта. При росте его проще разделить.
Как принять решение
- Опишите, какую конкретно проблему вы решаете: скорость релизов, конфликты, миграция.
- Проверьте, нельзя ли решить ее дешевле — модулями, монорепозиторием, feature-флагами.
- Если делить — делите по бизнес-доменам, а не по техническим слоям.
- Заранее выделите общую дизайн-систему и контракты между частями.
- Начните с одного выделенного куска и измерьте влияние на скорость загрузки.