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

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

Микрофронтенды: что такое и зачем нужно

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

Главная задача микрофронтов — разделить зоны ответственности, ускорить time-to-market и позволить разным командам работать и релизить параллельно.

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

Наш опыт внедрения микрофронтендов

Приложение RUN

Расскажу немного о нашем проекте. У нас есть приложение, которое называется RUN и оно является внутренним приложением для работы наших разных департаментов в рамках брокерейдж бизнеса. Оно содержит в себе такие  направления: бэкофис, срм, мониторинг, сервис управления ролями/ пермишенами, репортами, брендинг сервис и многое многое другое.

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

И да, RUN - это большой набор микрофронтенд приложений, но об этом позже.

Зачем нам понадобилась микрофронтендная архитектура

Изначально у нас был целый зоопарк внутренних проектов для разных департаментов. Это были старые проекты на разных стеках — Angular, jQuery, Vue.js, десктопные приложения и Django-админки.

В этом зоопарке были следующие проблемы:

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

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

• Копипаст логики. Общей дизайн-системы не было, интерфейсы выглядели разрозненно.

• Разные точки входа. Каждое приложение требовало отдельной авторизации.

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

В команде было всего 3-4 фронтенд-разработчика. До начала разработки была сделана дизайн-система, которую мы вынесли в отдельный UI-kit. Но чтобы переписать все, по оценкам, требовалась пара лет. Тогда бизнес спросил, можем ли мы интегрировать старые веб-приложения в наш проект, как есть, не дожидаясь реализации новых приложений. При этом необходимо было сохранить независимость и новых, и старых приложений в плане релизов — чтобы мы могли релизить каждое приложение, когда угодно.

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

Как все реализовано сейчас

• Приложение-контейнер или хост-приложение, в котором подключаются все микрофронтенд-приложения.

• UI-kit в npm — свой npm Registry в Nexus.

• Конфиги линтера, преттира и typescript вынесены в отдельные npm-пакеты. К этому мы пришли, потому что разработчикам нередко нужно подключаться на разные проекты. Чтобы смена проекта проходила бесшовно, мы решили использовать единый стиль, библиотеки и технологии.

• Все приложения и UI-kit у нас собираются на Vite. Все сборки — и прод, и дев, работают очень быстро. У Vite под капотом есть tree shaking, который позволяет уменьшать размер бандлов и не тянуть неиспользуемый код в проект. Мы тянем свои зависимости для каждого проекта, но для нас это некритичная проблема.

• Один шаблон для CI-конфигов, который гораздо проще поддерживать.

Наше приложение — контейнер (хост). В нем реализован лэйаут — меню/хидер и т.п., роутинг, авторизация и базовые настройки пользователя. На каждый роут рендерится нужное нам приложение, путь до которого берется по ключу из единой брендинг-системы. Меню также берется из настроек брендинга в соответствии с ролями пользователя и доступным набором приложений.

В MFE приложении у нас все максимально просто: мы кладем рендер проекта по ключу в Window. Приложения публикуются независимо и доступны для использования отдельно даже без приложения-контейнера по своему выделенному хосту. Поэтому делаем проверку, где запускается приложение.

В приложении-контейнере у нас тоже все достаточно просто. Рендерим компонент на определенный роут и вызываем хук useModuleInit с ключом конкретного проекта.

В хуке useModuleInit мы используем React 19. У него в React Dom из коробки есть метод ModuleInit, который может загружать внешние модули. Это решение у нас появилось с React 19. Раньше мы просто подключали скрипты через Helmet плагин, но это выглядело громоздко и костыльно, а сейчас гораздо проще.

Скрипт микрофронта разово подключается при заходе на роут. Он не перезапрашивается повторно при изменении url, а кешируется после первой подгрузки.

В микрофронтах есть много подходов (Module federation, Single-SPA и т.д.). Но мы не стали заморачиваться с их настройками: решение через ModuleInit нас более чем устраивает, не принуждает тянуть дополнительные библиотеки и настраивать конфиги.

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

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

Что дала нам микрофронтенд архитектура

При реализации этого подхода мы получили следующие преимущества:

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

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

3. Получили общий контекст. Команда стала отвечать за продукт в целом, стало меньше разрозненности в ответственности.

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

5. Упростили поддержку CI/CD. Появился единый шаблон конфигов.

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

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

Самое главное: мы снизили косты на поддержку и разработку.

Что важно учесть

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

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

• Соберите UI-kit. Ради консистентности дизайна и переиспользования UI-компонентов, чтобы по 100 раз не писать свой дропдаун.

• Подберите общий набор линтеров, утилит, конфигов и т.п. для единого стиля написания кода. Если между проектами предполагается ротация разработчиков, точка входа для них будет гораздо ниже. В целом, унификация экономит время.

• Настройте обмен знаниями между командами. Чтобы сотрудники не изобретали велосипеды, им нужно создать условия для взаимодействия и обмена опытом. Связующими звеньями могут быть лид и продакты.

• Предусмотрите увеличение нагрузки DevOps-инженеров. Микрофронты подключаются по сетевым запросам, поэтому нужно учесть настройки CORS и правильно настроить кеширование.

• Предусмотрите увеличение нагрузки лида. Активное участие тимлида или техлида очень нужно, чтобы вовремя за всем следить. У меня был опыт на проекте с микрофронтами, у которого не было лида: там был полный бардак с кодовой базой, все писали приложения, как хотели, добавляли собственные компоненты, библиотеки и периодически копипастили код друг у друга. Дальнейшая поддержка была очень дорогостоящей и сложной.

• Учитывайте общие зависимости. Поскольку приложения полностью независимы друг от друга, каждое тянет свои зависимости — соответственно, увеличивается размер бандла. В оптимизации бандлов поможет tree shaking.

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

Как понять, нужны ли вам микрофронтенды

Я собрал два чек-листа, в которых вы можете мысленно проставить галочки. 

Микрофронты нужны, если:

• У проекта минимальный time-to-market.

• Важны независимые релизы.

• Сложно поддерживать единое приложение из-за большой команды, конфликтов, сложного рефакторинга. Отрефакторить микрофронты и перейти, например, на новую версию React проще, когда делаешь это на небольшом приложении. Все проблемы решаются гораздо быстрее, а остальные проекты можно потом быстро перевести по шаблону.

• Много изолированных фич без общего стейта.

• Разношерстный стек/легаси, но нужна одна точка входа. Тут микрофронты суперполезны, можно временно интегрировать легаси-проект и мигрировать поэтапно.

Микрофронты не нужны, если:

• Небольшая команда или небольшое приложение/стартап/MVP.

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

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

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

Выводы

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

Наша архитектура полностью продиктована требованиями бизнеса:

• переход на приложение с единой точкой входа,

• интеграция старых приложений как временное решение,

• изолированность и независимость приложений, чтобы можно было сетапить любой набор.

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

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