Елизавета Акманова

Ведущий аналитик

Введение

Привет, Хабр!

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

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

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

Поехали!

Монолитный фронт

Начнем со сравнения с монолитом.  

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

• Контент

Текстовые данные, локализация и статические материалы (инструкции, FAQ, наименования элементов интерфейса), которые наполняют продукт смыслом

• Компоненты

Переиспользуемые UI-блоки (формы, карточки, навигация), обеспечивающие консистентность и ускоряющие разработку

• Ресурсы

Медиаконтент (изображения, иконки, видео), формирующий визуальную идентичность продукта

• Фреймворк

Архитектурный фундамент (React, Vue, Angular), определяющий принципы организации кода и workflow разработки

• Хранилище состояния

Централизованное управление данными, синхронизирующее информацию между компонентами

• Пакеты

Библиотеки утилит, устраняющие дублирование кода и стандартизирующие решения

• Шрифты

Типографика, влияющая на читаемость и восприятие бренда

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

Однако через время реальность меняется. Наше приложение разрастается:

• Кодовая база увеличивается в разы

• Производительность системы снижается

• Порог входа для новых разработчиков становится существенно выше

• Поддержка и развитие требуют всё больше ресурсов

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

Такой подход не является плохим - он просто имеет свою область применения.

Микрофронты

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

В чем заключаются архитектурные особенности такого похода: 

1. Доменная изоляция

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

2. Независимая сборка и деплой

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

1. изменения в одном модуле не требуют пересборки всего приложения

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

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

3. Единая точка входа (Shell/Контейнер)

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

Банальный пример

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

Микрофронты друг в друга мы встраиваем с помощью iframe. iframe — это стандартный HTML-элемент для встраивания на страницу полностью независимых документов. В микрофронтендной архитектуре он работает как «контейнер»: каждый микрофронт загружается в свой iframe, получая изолированную среду — отдельное DOM-дерево, CSS-стили и JavaScript-контекст. Это гарантирует, что компоненты не конфликтуют между собой, даже если используют разные библиотеки или версии фреймворков. Такой подход похож на запуск нескольких мини-приложений в отдельных вкладках браузера, но внутри одной страницы.

Проще говоря: iframe даёт максимальную изоляцию «из коробки», но требует аккуратного управления (например, для связи между микрофронтами придётся использовать postMessage).

Но не все так просто…

Как вы думаете, можно ли добиться полной изоляции микрофронтов друг от друга? Как например это сделано на бэке…

…пару минут паузы…

Несмотря на все преимущества декомпозиции интерфейса на независимые микрофронты, мы сталкиваемся с фундаментальными ограничениями браузерной среды: единое пространство window, общие механизмы хранения (localStorage, sessionStorage), сингулярность адресной строки и глобального контекста выполнения. В отличие от микросервисной архитектуры бэка, где сервисы могут быть полностью изолированы, фронтенд-компоненты вынуждены сосуществовать в рамках одной страницы, что неизбежно создает определенные точки взаимодействия.

Где нужен такой подход

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

• у вас появится больше сборок, больше точек отказа

• нужно будет продумать контракты, управление зависимостями, маршрутизацию

• всё это надо поддерживать в долгую

Выводы

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

А во второй части — самое интересное: как мы переходили с монолита на микрофронты. Расскажу про подводные камни, решения и лайфхаки, которые помогли нам не утонуть в этой трансформации. Продолжение следует! ?