Вступление

Меня зовут Некипелов Иван, я технический руководитель команды фронтенд инфраструктуры в Wildberries & Russ. Последние несколько лет мы с командой развиваем архитектуру и инфраструктуру большого frontend-продукта.
В этой статье разберу наш путь от монолита к микрофронтендам:  расскажу как решали ключевые проблемы и с какими сложностями столкнулись во время миграции.

Контекст

Прежде чем рассказать про нашу имплементацию микрофронтенд-архитектуры, стоит немного погрузиться в контекст разработки на момент появления первого микрофронтенда.

Изначально проект представлял собой монолитный .NET-репозиторий с бекендом и legacy-фронтендом. Со временем фронт был вынесен в отдельный репозиторий и отделён от бека на уровне инфраструктуры: deploy, CI/CD и процессов разработки.

Параллельно началась постепенная миграция с legacy-решений на современный React-стек, про данную миграцию и пойдёт сегодня речь в контексте микрофронтендов.

Таким образом наш frontend-проект на начало внедрения микрофронтенд архитектуры представлял собой большой монолитный SPA внутри одного репозитория и одного процесса сборки. Исторически приложение росло много лет: появлялись новые домены, команды, бизнес-направления, и со временем это привело к типичным проблемам крупного монолита.

Основные особенности нашей монолит архитектуры:

• общие глобальные зависимости, связанные через “god object”;

• сильная связанность между модулями;

• сложная система legacy-инициализации и сборки;

• большой объём общего кода без четких границ ответственности;

• долгий регресс и медленная выкатка релизов;

• высокая стоимость изменений.

Схематично до выделения микрофронтов архитектура представляла собой стандартный feature-oriented подход организации кода:

Зачем нам понадобились микрофронтенды?

По мере роста продукта увеличивалось количество команд, релизы становились тяжелее, а стоимость регресса — выше.

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

Наша реализация:

• Монорепозиторий Lerna (Nx) как единый контур разработки для host и всех микрофронтов

• Рантайм загрузка приложений через Webpack module federation

• Разделяемся по страницам, иногда по виджетам, если у команды нет страниц в ответственности

• Общий код вынесен в packages и подключается в приложения как зависимости в node_modules через симлинки (symbolic links)

• В packages держим только переиспользуемые технические и платформенные модули, никакой бизнес-логики

• Общая бизнес-логика переиспользуется через DI-контейнер: host регистрирует сервисы, микрофронты используют их по контрактам.

• Host также является микрофронтом и может шарить общие виджеты

Физическая архитектура:

Как мы переиспользуем бизнес-логику

Как было отмечено выше, от легаси нам достался большой слой бизнес-сущностей: по сути, множество синглтонов, которые явно и неявно связаны друг с другом.

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

Проблема возникает, когда один и тот же сервис нужно переиспользовать между несколькими приложениями.

На первый взгляд, вынести такой код в packages кажется очевидным решением, но на практике это ломает архитектурные границы: пакетный слой должен оставаться техническим и платформенным, без привязки к доменной логике конкретного приложения. Иначе packages быстро превращаются в общий бизнес-слой, который сложно развивать независимо.

Экспорт бизнес-сервисов напрямую через Module Federation тоже оказался неудачным решением.

Во-первых, такой подход создаёт сильную связанность между микрофронтами. Один микрофронт начинает напрямую зависеть от runtime другого приложения, его структуры, порядка инициализации и конкретной реализации сервисов. В результате независимость микрофронтов становится скорее формальной и мы рискуем получить монолит ещё сложнее и тяжелее в поддержке, чем был, где каждое приложение жестко зависит от другого.

Во-вторых, возникают проблемы с жизненным циклом и состоянием singleton-сервисов. Нет гарантии, что сервис будет инициализирован ровно один раз, особенно если разные приложения начинают импортировать его в разное время или в разных режимах загрузки. Это легко приводит к дублированию состояния и ошибкам, которые сложно отлаживать.

Кроме того, появляется проблема версионирования. Любое изменение внутренней реализации или API сервиса начинает влиять на все приложения, которые его потребляют через federation. В итоге вместо независимого деплоя микрофронтов получается распределённый монолит с высокой связностью.

Module federation хорошо подходит для экспорта UI-слоя — страниц, виджетов, компонентов, но плохо подходит для шаринга сложного бизнес-runtime. Бизнес-сервисы обычно имеют большое количество скрытых зависимостей, побочных эффектов и привязку к инфраструктуре приложения, из-за чего становятся слишком хрупкими для прямого runtime-шаринга.

Поэтому в качестве границы между приложениями мы используем контракты и Dependency Injection (DI).

Решение заключается в том, чтобы вынести в отдельный пакет интерфейсы сервисов. Важно, что в таком пакете могут находиться только типы и контракты — в рантайме этой библиотеки фактически не существует.

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

Таким образом целевая модель архитектуры:

• host отвечает за shell, роутинг, DI, shared runtime и загрузку микрофронтов;

• микрофронты отвечают за свои страницы/виджеты и доменную реализацию;

• packages содержат только техническую платформу, UI-kit, утилиты, типы и контракты;

• бизнес-реализации не шарятся напрямую между приложениями;

• общение между частями системы идет через контракты, DI и публичные API.

Как мы загружаем микрофронты

Архитектурные границы описаны, теперь разберем, как микрофронты загружаются и подключаются в runtime хостового приложения.

Подключение микрофронтов в режиме локальной разработки и на dev-стендах опустим — это отдельная большая тема. Здесь сфокусируемся на production-сценарии.

Каждый релиз микрофронта имеет собственную версию. Фактически собранный микрофронт — это remoteEntry.js с версией в имени и набор скомпилированных JavaScript-файлов, которые этот remoteEntry загружает при инициализации.

В production host не содержит код микрофронтов внутри своего bundle. Вместо этого он знает конфигурацию доступных remotes: имя микрофронта, его production-версию и путь до remoteEntry.

У нас это сделано через promise-based remotes в Module Federation.

То есть remote описан не как статический URL, а как promise-proxy с get/init/__load, и микрофронт подгружается декларативно, по обращению к нему. Ниже псевдокод описывающий инициализацию контейнера с микрофронтендом

Важно, что такая реализация не загружает микрофронтенд при старте приложения.

Пока к конкретному remote нет обращения, init просто возвращает Promise.resolve().

Это снижает риск падения на этапе инициализации и откладывает загрузку микрофронта до реального запроса.

Когда пользователю нужна страница или виджет из микрофронта, host:

1. определяет нужный remote

2. собирает URL до его remoteEntry.js

3. загружает этот файл в runtime

4. инициализирует Module Federation shared scope

5. получает exposed module из микрофронта

6. рендерит нужную страницу, компонент или виджет внутри host-приложения

Как мы управляем версиями микрофронтов

Каждый микрофронт выкатывается как отдельная версионированная сборка. Сам по себе релиз — это выгрузка статики в статическое хранилище. Host загружает нужную версию remote в runtime на основе конфигурации.

Для управления версиями у нас есть админка. Через неё можно быстро переключить prod-версию конкретного микрофронта, протестировать новую сборку на отдельном окружении или откатить проблемный релиз.

Схематично это выглядит так

Совместимость версий микрофронтов

Независимые релизы микрофронтов создают ещё одну проблему: host и remote могут (и должны) обновляться не одновременно. Не всегда получается обеспечить обратную совместимость релизов, например, при обновлении мажорной версии реакта обновлять сразу нужно и хост, и микрофронты или при изменении какого-то общего сервиса, где нельзя по каким-то причинам обеспечить старое поведение или старый интерфейс.

Чтобы избежать runtime-конфликтов, у нас появился дополнительный слой compatibility management.

Для каждого микрофронта мы поддерживаем таблицу совместимости версий host ↔ remote. Она описывает, какая версия микрофронта совместима с конкретной версией host-приложения.

Упрощенно это выглядит так:

Во время загрузки remote host проверяет собственную версию и на основе compatibility-правил определяет, какую именно версию микрофронта необходимо загрузить.

Это позволяет:

• безопасно выкатывать несовместимые изменения постепенно;

• делать rollback отдельных микрофронтов без отката всего приложения;

Shared dependencies

Отдельной сложностью при внедрении Module Federation стали shared dependencies.

На первый взгляд кажется, что достаточно вынести общие библиотеки в shared, и они автоматически начнут переиспользоваться между host и микрофронтами. На практике это оказалось одним из самых чувствительных мест всей архитектуры.

Во-первых, у shared-пакетов в Module Federation фактически нет привычного tree shaking на уровне потребления. В runtime часто подтягивается весь shared-пакет, а не только те части, которые реально используются конкретным микрофронтом. Из-за этого шаринг зависимостей не всегда уменьшает размер приложения: иногда он, наоборот, увеличивает общий объём загружаемого кода.

Во-вторых, если host и remote начинают поставлять разные версии одной и той же библиотеки, появляется риск runtime-конфликтов. В compile-time это может выглядеть корректно, но в production конкретная комбинация версий host и микрофронта может привести к падению приложения.

Самые критичные зависимости в этом смысле:

• react;

• react-dom;

• react/jsx-runtime;

• роутер;

• state/context-библиотеки;

• UI-kit, если внутри него есть контексты;

• платформенные runtime-библиотеки вроде DI, settings, analytics, i18n.

Особенно опасны библиотеки, которые держат состояние или используют React Context. Если такие зависимости задублируются между host и remote, приложение может получить несколько независимых runtime-копий одной и той же библиотеки. В результате компоненты визуально могут быть загружены корректно, но контексты, хуки или singleton-сервисы начнут работать неконсистентно.

Отдельный нюанс — subpath imports. Для корректного шаринга недостаточно указать только основной пакет. Если код импортирует не только @wildberries/spa-services, но и, например, @wildberries/spa-services/hooks, такие subpath-импорты тоже должны быть явно описаны в shared. Иначе Module Federation может считать их разными модулями, что приводит к дублированию кода и runtime-конфликтам.

Поэтому shared — это не просто оптимизация размера bundle. Это часть runtime-контракта между host и микрофронтами. Любая ошибка в shared-конфигурации может привести не только к увеличению веса приложения, но и к production-ошибкам, которые сложно воспроизвести локально.

В итоге мы пришли к правилу: в shared нужно выносить только те зависимости, для которых действительно важен единый рантайм инстанс или которые слишком дороги для дублирования. Все остальное лучше оставлять внутри конкретного микрофронта, чтобы не усложнять shared scope без необходимости.

Обратная совместимость и требования к кодовой дисциплине

Подобная архитектура дает командам значительно больше независимости, однако вместе с этим повышает требования к инженерной дисциплине.

Поскольку микрофронты выкатываются независимо и подключаются в runtime, система больше не может полагаться на то, что все части приложения обновляются одновременно. В любой момент времени host и разные микрофронты могут работать на разных версиях.

Из-за этого обратная совместимость становится не рекомендацией, а обязательным требованием архитектуры.

Любое изменение:

• публичного API

• shared-контрактов

• интерфейсов сервисов

• exposed module

• shared dependency

• runtime-поведения

должно проектироваться с учётом того, что часть системы может еще некоторое время работать на предыдущей версии.

Особенно важно аккуратно работать с:

• singleton-сервисами

• shared state

• DI-контрактами

• Module Federation shared dependencies

• React/UI-library версиями

Фактически микрофронтендная архитектура переносит часть сложности из compile-time в runtime. Если в монолите многие проблемы обнаруживаются во время сборки, то в распределённой рантайм архитекутре ошибки совместимости могут проявляться уже в production при конкретной комбинации версий host и remote.

Поэтому подобная архитектура требует:

• строгих правил версионирования

• четких архитектурных границ

• аккуратной работы с обратной совместимость

• контроля shared dependencies

• стабильных контрактов между приложениями

• дисциплины при удалении и изменении API пакета/сервиса и т.п.

• мониторинга runtime-ошибок

Без этого микрофронтенды очень быстро могут превратиться в распределённый монолит с ещё более сложной отладкой и поддержкой, чем исходное приложение.

Что мы получили в итоге

Прежде всего микрофронтенды дали возможность локализовать изменения внутри отдельных доменных областей. Команды получили более независимый цикл разработки и стали значительно меньше влиять друг на друга при внесении изменений.

Дополнительно удалось:

• сократить размер и время сборки основного host-приложения;

• разделить ownership между командами;

• уменьшить стоимость регресса;

• упростить rollback отдельных частей системы;

• перейти от “одного тяжелого релиза” к независимым выкладкам отдельных доменов.

Однако вместе с преимуществами микрофронтенды принесли и новый уровень сложности.

Часть проблем, которые раньше решались на этапе сборки, переместилась в runtime:

• контроль shared dependencies;

• singleton runtime;

• совместимость версий;

• порядок инициализации;

• runtime-конфликты;

Кроме того, существенно выросли требования к архитектурной дисциплине. В монолите многие неудачные решения могут оставаться незаметными достаточно долго, тогда как в распределенной runtime-архитектуре ошибки в контрактах, shared dependencies или версионировании начинают проявляться значительно быстрее и сложнее диагностируются.

В результате микрофронтенды оказались не “серебряной пулей”, а скорее инструментом управляемого масштабирования большого SPA. Они хорошо решают проблемы роста команд, доменов и релизных циклов, но требуют зрелой платформенной инфраструктуры, четких архитектурных границ и высокой инженерной дисциплины.

Заключение

Спасибо, что прочитали статью.

Если у вас был похожий опыт перехода к микрофронтендам, делитесь в комментариях своими кейсами, удачными решениями и ошибками.