独立站微前端：多团队协作、技术栈隔离与部署独立性
1. Какую задачу на самом деле решают микрофронтенды
Микрофронтенды разбивают фронтенд-приложение по бизнес-доменам на несколько подприложений. Каждое подприложение разрабатывает и деплоит отдельная команда, а затем «оболочка» (Shell) собирает их на одной странице. Аналогия с микросервисами на бэкенде: большую систему разбивают на сервисы с независимым деплоем — во фронтенде можно сделать так же.
Они закрывают три конкретные боли. Первая: несколько команд правят код в одном репозитории, конфликты слияния случаются всё чаще. Вторая: команда A хочет обновиться до React 19, команда B всё ещё на React 17 — они тянут друг друга. Третья: мелкое изменение требует полной сборки и релиза всего сайта, регрессионное тестирование покрывает весь сайт, риски растут. Все три боли порождены масштабом организации, а не нехваткой технических компетенций.
Контринтуитивный вывод: выгода от микрофронтендов пропорциональна размеру команды. Чем меньше команда, тем больше убытков от микрофронтендов. Фронтенд-команда из 3 человек, раздробив проект на микрофронтенды, добавляет себе три лишних слоя сложности — оболочку, координацию роутинга и межприложенческую коммуникацию, — хотя проблем с конфликтами слияния у неё изначально нет. Как выбрать стек для WordPress — см.Выбор стека WordPress.
| Показатель | Микрофронтенды не нужны | Можно рассмотреть микрофронтенды | Микрофронтенды обязательны |
|---|---|---|---|
| Число фронтенд-команд | 1 | 2 | 3 и больше |
| Строк в репозитории | Меньше 100 000 | От 100 000 до 500 000 | Больше 500 000 |
| Разница в релизных циклах | Единый, раз в неделю | Часть команд обновляется раз в месяц | Смешанные: недельные и ежедневные |
| Конфликты стеков | Полностью единый | Незначительные конфликты | Несколько фреймворков одновременно |
| Тип продукта | Чисто маркетинговый сайт | Маркетинговый сайт + простая админка | Маркетинговый сайт + сложный SaaS + админка |
| Сложность деплоя | Один репозиторий, одна сборка | Один репозиторий, несколько сборок | Несколько репозиториев, несколько сборок |
2. Три распространённых подхода к реализации: как выбрать
Первый — Module Federation, встроенная возможность webpack 5: дочернее приложение при сборке объявляет, какие модули предоставляет, а главное загружает их во время работы. Плюс — высокая степень интеграции, минус — версии webpack должны совпадать, а отладка сложнее. Подходит командам на React/Next.js, которые уже используют webpack.
Второй — import-map + SystemJS: URL дочерних приложений объявляются в JSON-файле во время работы, а главное приложение загружает их по мере необходимости. Плюс — полная изоляция технологических стеков, дочерним приложением может быть React, Vue или Svelte на выбор. Минус — изоляцию стилей между приложениями и согласование маршрутов придётся делать самим.
Третий — монорепозиторий с несколькими приложениями (Monorepo + несколько независимых сборок): например, Nx или Turborepo управляют несколькими подпакетами, каждый собирается и разворачивается отдельно. Плюс — удобно делиться кодом, минус — чем больше репозиторий, тем медленнее сборка, для очень больших команд не подходит. Как выстроить перелинковку, смотрите в системой внутренних ссылок.
| Подход | Изоляция технологий | Порог входа | Сложность сборки | Для какого масштаба |
|---|---|---|---|---|
| Module Federation (Webpack 5) | Средняя (единый основной фреймворк) | 2–3 недели | Средний | Команда на React, 20–50 человек |
| import-map + SystemJS | Высокая (можно смешивать фреймворки) | 3–4 недели | Высокий | Несколько фреймворков, более 50 человек |
| Monorepo + несколько приложений | Низкая (общие зависимости) | 1–2 недели | Низкая | Несколько команд на одном фреймворке, 10–30 человек |
| Микрофронтенды на iframe | Очень высокая | Крайне низкая | Низкая | Временная интеграция сторонних страниц |
III. Когда B2B-сайту действительно нужны микрофронтенды
Чисто маркетинговому B2B-сайту — только главная, страницы товаров, блог, «О нас», «Контакты» — микрофронтенды не нужны. Кода на таких сайтах обычно меньше 50 000 строк, с поддержкой справится и один человек, а разбиение на микрофронтенды — это лишние хлопоты на пустом месте.
Микрофронтенды действительно нужны сайтам, где сочетаются маркетинг, клиентский портал и партнёрская админка. Например, выходящая на зарубежные рынки промышленная платформа: контентом сайта занимается маркетинговая команда (Next.js, приоритет — SEO), системой заказов и запросов клиентов — продуктовая команда (React, приоритет — интерактивность), админкой для дилеров — команда эксплуатации (Vue, приоритет — инструменты). У трёх команд разный ритм релизов, разные технологические стеки и более 100 000 строк кода у каждой. В такой ситуации микрофронтенды собирают три дочерних приложения в разные маршруты одного домена, и каждая команда разворачивает своё независимо, не мешая остальным. Как настроить мониторинг сайта для нескольких приложений, смотрите в Мониторинг сайта и оповещения.
Пример из практики: выходящая на зарубежные рынки SaaS-компания, сайт на Next.js, пользовательская панель на React+Redux, изначально два приложения разворачивались на разных поддоменах. Потом выяснилось, что после входа пользователь переходит с сайта на панель через другой домен и опыт рвётся. С помощью Module Federation оба приложения объединили в одно главное: единая навигация, общее состояние входа, независимое развёртывание. Правки сайта не влияют на панель, правки панели не влияют на сайт, частота релизов выросла с раза в неделю до двух раз в день.
| Задача | Как это делают монолитные приложения | Как это делают микрофронтенды | Выгода |
|---|---|---|---|
| Частота релизов | Полная регрессия, раз в неделю | Независимый деплой подприложений, несколько раз в день | Скорость релиза выше в 5–10 раз |
| Обновление стека | Обновлять всё сразу — большой риск | Обновляем подприложения по одному | Цикл обновления: с кварталов до недель |
| Командная работа | Частые конфликты слияния в одном репозитории | Отдельные репозитории, общий контракт API | Конфликтов слияния меньше на 80% |
| Зона влияния сбоя | Один баг роняет весь сайт | Падение подприложения затрагивает только его часть | Радиус поражения при сбое меньше |
| Ввод нового сотрудника | Нужно знать весь сайт | Достаточно знать своё подприложение | Срок ввода в работу: с 4 недель до 1 |
Четыре. Три главные ловушки микрофронтенда
Первая ловушка: стили конфликтуют друг с другом. Оба подприложения используют Bootstrap, загружаются на одну страницу — и стили превращаются в кашу. Решение — пространства имён в CSS (префикс для каждого подприложения) или изоляция через Shadow DOM. Это не техническая проблема, но правила нужно зафиксировать в самом начале проекта, иначе потом править будет мучительно.
Вторая ловушка: связь между приложениями. Пользователь заполнил форму на маркетинговом сайте и хочет перенести данные в дашборд личного кабинета. Если подприложения полностью независимы, связь придётся строить через параметры URL или localStorage — а с ростом объёма данных начинается хаос. Решение — глобальное управление состоянием в оболочке (например, zustand), а подприложения читают и пишут через оговорённый интерфейс. Не позволяйте подприложениям вызывать друг друга напрямую.
Третья ловушка: фрагментация производительности. Каждое подприложение грузит свою копию React — пользователь скачивает три копии, и общий объём JS вырастает с 500 КБ до 1,2 МБ. Решение — вынести общие зависимости вроде React и Vue в оболочку, а подприложения подключают их через общую область видимости, без повторной сборки. Как навести порядок в сторонних скриптах, читайте в Управление сторонними скриптами.
| Ловушка | Симптом | Решение | Предупреждающие действия |
|---|---|---|---|
| Конфликт стилей | Кнопка подприложения A выглядит как кнопка подприложения B | Префиксы CSS или Shadow DOM | Задать правила стилей в начале проекта |
| Хаос в общем состоянии | Данные между подприложениями теряются | Единое управление состоянием в оболочке | Договориться об общих интерфейсах и структурах данных |
| Дублирование объёма JS | Каждое подприложение собирает свою копию фреймворка | Общие зависимости поднимаем в оболочку | Анализ дублирующихся бандлов при сборке |
| Рассинхрон маршрутов | После обновления подприложение отдаёт 404 | Единое управление маршрутами в оболочке | Централизованная настройка правил маршрутизации |
| Сложно отлаживать | Непонятно, из какого подприложения ошибка | Единый мониторинг ошибок + метки подприложений | Sentry с тегом подприложения |
FAQ: частые вопросы
Чем микрофронтенд отличается от iframe? Почему бы просто не использовать iframe?
Фронтенд-команда из 5 человек, 80 тысяч строк кода — стоит ли разбивать на микрофронтенды?
Замедлят ли микрофронтенды загрузку первого экрана?
Можно ли сделать микрофронтенды на WordPress?
Как выстроить деплой микрофронтендов?
Влияют ли микрофронтенды на SEO?
В заключение
Микрофронтенды — это архитектурное решение, продиктованное масштабом. Пока команда маленькая, это обуза; когда команда большая — это спасение. Прежде чем решать, дробить ли систему, смотрите не на технологическую моду, а на свои реальные боли: каждую неделю разгребаете конфликты слияния? Чтобы поправить одну строчку текста, приходится прогонять полный регресс? Две команды блокируют друг друга из-за разных стеков? Если на два из трёх вопросов ответ «да» — тогда думайте о дроблении.
На практике начинайте с самой болезненной точки: вынесите отдельно то приложение, которое релизится чаще всего (обычно это страница маркетинговых акций), остальное пока не трогайте. Через три месяца оцените результат: если после независимого релиза скорость выросла и конфликтов слияния стало меньше — дробите второе. Не разбивайте весь сайт сразу на пять-шесть микрофронтендов — это яма, которую вы сами себе роете.
Запомните одну фразу: микрофронтенды — это скальпель для «больших команд, которые уже не могут не дробить», а не украшение для «сайта, который ещё не вырос». Если команда не доросла до такого масштаба, дробление только превратит простую задачу в сложную.