Содержание
Микрофронтенды — это подход, при котором большой интерфейс делится на независимые части, которые разные команды разрабатывают и выпускают отдельно. Они оправданы, когда над одним продуктом работают несколько команд и общий релиз всех тормозит. Небольшой команде микрофронтенды обычно приносят больше сложности, чем пользы, — ей подходит модульный монолит.
Разберём, какие проблемы решают микрофронтенды, как их собирают, во что обходится такой подход и что выбрать вместо него.
Какие проблемы решают микрофронтенды?
Микрофронтенды решают организационные проблемы, а не технические: они дают командам независимость. Когда десять человек из разных команд правят один репозиторий фронтенда, релиз одной функции ждёт проверки всех остальных, а конфликты в коде становятся ежедневными.
Что дают микрофронтенды:
- независимые релизы — команда каталога выпускает изменения, не дожидаясь команды оплаты;
- чёткие границы ответственности — каждая часть интерфейса принадлежит одной команде;
- постепенная миграция — старый интерфейс заменяется по кускам, а не переписывается целиком;
- изоляция сбоев — ошибка в одном виджете не роняет всю страницу.
Это та же логика, что и у микросервисов на бэкенде, с теми же компромиссами — мы разбирали их в статье монолит или микросервисы.
Как собирают микрофронтенды?
Части интерфейса собирают в одну страницу на сервере, в браузере во время выполнения или через iframe. Выбор зависит от требований к SEO, скорости загрузки и степени изоляции.
| Способ | Как работает | Плюсы | Минусы |
|---|---|---|---|
| Сборка на сервере | Сервер склеивает HTML из фрагментов | Хорошо для SEO и скорости | Сложнее инфраструктура |
| Module Federation | Браузер подгружает модули других приложений | Общие зависимости, гибкость | Связанность версий, сложная отладка |
| Web Components | Части оформлены как пользовательские элементы | Не зависит от фреймворка | Ограничения в стилях и SSR |
| iframe | Каждая часть — отдельная страница | Полная изоляция | Неудобная навигация, вес, доступность |
Фото: Unsplash
Во что обходятся микрофронтенды?
Микрофронтенды усложняют всё, что раньше было общим: дизайн, зависимости, маршрутизацию, тестирование и производительность. Без дисциплины пользователь получает страницу с тремя версиями фреймворка, разными кнопками и долгой загрузкой.
Основные расходы:
- Производительность. Каждая часть может тянуть свои библиотеки — растёт объём JavaScript и время загрузки.
- Единый дизайн. Нужна общая дизайн-система, иначе интерфейс расползётся — подробнее в статье дизайн-система: когда нужна.
- Общие данные. Авторизация, корзина, настройки пользователя должны быть доступны всем частям.
- Инфраструктура. Отдельные сборки, деплой, версии и мониторинг для каждой части.
- Сквозное тестирование. Части выпускаются независимо, но работать должны вместе.
Что выбрать вместо микрофронтендов?
Небольшой команде чаще подходит модульный монолит: одно приложение, разделённое на модули с чёткими границами и правилами зависимостей. Он даёт порядок в коде и понятную ответственность без отдельной инфраструктуры для каждой части.
Признаки, что микрофронтенды пока не нужны:
- над фронтендом работает одна-две команды;
- релизы не блокируют друг друга дольше дня;
- продукт на одном фреймворке и не планирует миграцию;
- важны скорость загрузки и SEO публичных страниц.
Признаки, что пора:
- три и более команды постоянно конфликтуют в одном репозитории;
- нужно постепенно заменить старый интерфейс без остановки разработки;
- разные части продукта имеют разный цикл релизов и разных владельцев.
Про выбор фреймворка и типизацию — статьи Vue или React и TypeScript на фронтенде.
Как внедрять микрофронтенды, если решение принято?
Внедрять стоит постепенно: начать с оболочки, которая отвечает за навигацию и авторизацию, и вынести в отдельное приложение одну наиболее независимую часть. Только убедившись, что схема работает, переносить остальные.
- договоритесь об одном фреймворке и общих версиях ключевых библиотек;
- вынесите дизайн-систему в отдельный пакет;
- определите контракт общения частей: события, общий стор или URL;
- следите за размером JavaScript на каждой странице в CI.
Коротко
- Микрофронтенды решают организационную проблему — независимость нескольких команд.
- Способы сборки: на сервере, Module Federation, Web Components, iframe.
- Цена — производительность, единый дизайн, общие данные и инфраструктура.
- Одной-двум командам обычно лучше подходит модульный монолит.
- Внедряйте постепенно: оболочка, одна независимая часть, затем остальные.
Частые вопросы
Можно ли совмещать Vue и React в микрофронтендах?
Технически можно, но это увеличивает размер страницы и усложняет общий дизайн. Обычно разные фреймворки оставляют только на время постепенной миграции со старого стека на новый.
Как микрофронтенды влияют на SEO?
Если части собираются только в браузере, поисковикам сложнее увидеть контент. Для публичных страниц лучше сборка на сервере, а клиентская композиция подходит для личных кабинетов и админок.
С какого размера команды стоит думать о микрофронтендах?
Обычно когда над одним фронтендом работают три и более независимых команд и они регулярно мешают друг другу при релизах. Для одной-двух команд накладные расходы почти всегда выше пользы.
