Максимально простое объяснение устройства микрофронтендов

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

Для конечного пользователя сайт выглядит как единое целое, хотя на деле это несколько сшитых друг с другом сайтов, интегрированных друг с другом. Каждый такой фрагмент отвечает за свою область функциональности (например, поиск, личный кабинет, страница товаров ) и может развиваться независимо от других. Эти мини приложения могут быть созданы на разных технологиях и фреймворках, общаться через чётко определённые интерфейсы. Вместе они образуют клиентское приложение для работы. Так как отдельные части фронта независимы друг от друга, то сбой или изменение в одном модуле не выводит из строя весь сайт.

Пример Spotify, каждый раздел — это отдельные автономные приложения, склеенные в одном клиентском интерфейсе.

Рассмотрим такой подход с позиции менеджмента и разработки.

Разработка веб-приложения

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

Проект придётся сшивать из отдельных частей

Каждый микрофронтенд — это автономный проект с отдельным репозиторием и командой, что даёт гибкость в разработке и упрощает понимание кодовой базы той части, над которой предлагается работать. Но такой подход вынуждает постоянно согласовывать интеграции с другими командами, а ещё не факт, что в компании будет человек, который знает, как функционируют отдельные части. Если такого человека нет или он был и пропал, то разбираться придётся самостоятельно, а вникать в чужой код всегда долго и больно. Помочь избежать bus factor может хорошо составленная документация, а также соблюдение стандартов написания кода, единые для всех команд.

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

Максим ЧернухинCTO клиентского сервиса СберСтрахование Жизни

В проекте можно будет экспериментировать

В микрофронтендах каждая команда может выбирать свой стек под отдельные задачи — React, Vue, Angular или всё, что душе угодно . Это позволяет экспериментировать и постепенно внедрять новые технологии, не переписывая монолит. Но такая свобода — палка о двух концах: без строгих соглашений дизайн и UX могут стать разрозненными, а при запуске страницы — нагрузка дублирующихся библиотек будет бить по производительности.

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

Проект будет сложнее деплоить

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

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

Как применять в проекте

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

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

Максим ЧернухинCTO клиентского сервиса СберСтрахование Жизни

Webpack Module Federation

Module Federation — механизм, встроенный в Webpack 5, который позволяет одному фронтенду (host) динамически загружать модули из другого фронтенда (remote) во время выполнения. Это мощный инструмент для интеграции микрофронтендов: он поддерживает разделение кода, кэширование, совместное использование зависимостей (например, React или Vue) и независимую доставку каждого модуля. Module Federation работает без необходимости использовать iframe или перекомпиляции.

Инструкция по использованию

Менеджмент

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

Один проект превращается во множество

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

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

Команды будут независимы друг от друга

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

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

Команды получают поле для удачных и не очень экспериментов

Команды могут внедрять новые технологии, не дожидаясь переписывания всего приложения: один микрофронтенд можно сделать на React, другой — на Vue или Svelte. Это даёт гибкость в найме, миграциях и экспериментах. Но чем больше технологий используется, тем сложнее следить за их использованием и труднее помнить их особенности.

В какой-то момент менеджер вместо одной технологической карты управляет целой экосистемой со своими внутренними правилами.

Появляются FrontOps

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

Вывод

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

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

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня» отмечает, что микрофронты — не всегда удачное решение:

«Микрофронтенды — хорошее решение, если команды действительно автономны. Я видела примеры, когда проект разделяли на микрофронтенды, но при этом одно приложение зависело от другого: чтобы добавить фичу, необходимо было делать изменения сначала в одном месте, а затем в другом. Это — верный знак, что что-то пошло не так: в этом случае процесс разработки усложнится, а сроки затянутся. Прежде чем переходить на микрофронтенды, попробуйте логически разделить ваш проект по директориям и убедиться, что для изменения одной фичи в проекте приходится редактировать код только в одной директории. Следующим шагом можно переходить на микрофронтенды».

Делитесь своим опытом работы с микрофронтендами в комментариях и не забывайте сохранять наши статьи!