Микрофронтенды: 9 шаблонов для каждого разработчика

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

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

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

1. Микроприложения: сегментация по маршрутам

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

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

Но, поскольку каждым маршрутом загружается полное приложение вместе с его фреймворком, время загрузки каждого маршрута увеличивается. Это увеличение минимизируется кешированием в браузере, методами сжатия вроде GZip и Brotly, а также сетями доставки содержимого для общих ресурсов и пакетов JavaScript. Отложенная загрузка несущественных компонентов и ресурсов в фоновом режиме или при навигации тоже придется кстати.

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

Преимущества

• Полная автономия в разработке и выпуске: команды разрабатывают и выпускают функционал независимо друг от друга.
• Локализация неисправностей: общая надежность повышается изолированием проблем в отдельных микроприложениях.
• Минимальные зависимости между командами: уменьшается сложность межкомандных зависимостей и конфликтов интеграции.

Трудности

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

2. Микрофронтенды с iFrame: надежная встроенная изоляция

Надежная изоляция создается встраиванием каждого микрофронтенда в собственный iframe внутри главного приложения.

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

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

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

Преимущества

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

Трудности

• Сложное взаимодействие между этими iframe: требуются дополнительные фреймворки или системы обмена сообщениями.
• Накладные расходы на производительность: накладные расходы нескольких iFrame сказываются на производительности: использовании памяти, времени загрузки.
• Проблемы респонсивности: возможности сделать приложение респонсивным существенно ограничены, при адаптации к различным размерам экрана эти iFrame не такие гибкие.
• Ограничения безопасности браузера: части приложения в iframe не загружаются из-за средств безопасности браузера.
• Сокращение применения: использование iFrame постепенно сокращается, их будущая жизнеспособность ограничивается.

3. Микрофронтенды с App Shell: централизованная платформа для интеграции

Шаблон App Shell  —  центральное приложение-оболочка в виде платформы, на которой загружаются микрофронтенды.

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

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

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

Благодаря App Shell совершенствуется сквозная функциональность: аутентификация, управление состоянием, переходы между микрофронтендами. Так упрощается реализация, обеспечивается согласованность.

Преимущества

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

Трудности

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

4. Микрофронтенды с компонентами Bit: универсальная компонуемость

Микрофронтендами при помощи компонентов и инструментария Bit создаются легко сочетаемые переиспользуемые компоненты, которые разрабатываются, тестируются и развертываются независимо друг от друга.

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

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

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

Компоненты Bit сочетаются с различными методами интеграции: модульной федерацией, интеграцией во время сборки, объединением в пакеты.

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

Преимущества

• Хорошая компонуемость: поддерживается создание универсально сочетаемых компонентов, от небольших элементов пользовательского интерфейса до высокоуровневых компонентов бизнес-логики.
• Независимая разработка: каждый компонент разрабатывается, тестируется и развертывается независимо от других, команды становятся автономнее.
• Переиспользование кода: повышается благодаря управлению компонентами в облаке Bit, обеспечивается согласованность, сокращается дублирование.
• Эффективное управление зависимостями: в Bit зависимости контролируются на уровне компонента, дублирование предотвращается использованием совместимых зависимостей.
• Гибкость интеграции: применяется с модульной федерацией или интеграцией во время сборки, чем обеспечивается гибкость интеграции компонентов в приложение.
• Межкомандное взаимодействие: упрощается совместная работа разных команд, даже если компонент принадлежит другой команде.
• Визуализация зависимостей: визуализируются зависимости между микрофронтендами и компонентами, благодаря этому оценивается влияние изменений.
• Эффективная непрерывная интеграция: в Ripple CI собираются только соответствующие зависимости из графа зависимостей, эффективность повышается.

Трудности

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

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

5. Микрофронтенды с NPM: модульная разработка с NPM-пакетами

Этим шаблоном каждый микрофронтенд заключается в NPM-пакет, так что команды разрабатывают, тестируют и развертывают независимо друг от друга. Шаблон применяется с приложением-оболочкой, при помощи которой пакеты объединяются.

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

Команды работают над микрофронтендами независимо друг от друга и выпускают обновления в виде новых версий NPM-пакетов.

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

Преимущества

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

Трудности

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

6. Модульная федерация: динамическая загрузка во время выполнения

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

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

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

Преимущества

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

Трудности

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

7. Бэкенд для микрофронтенда

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

Преимущества

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

Трудности

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

8. Микрофронтенды на основе порождения событий: респонсивный оркестр

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

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

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

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

Преимущества

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

Трудности

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

9. Шаблон Hypermedia: динамический навигатор

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

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

Отличие шаблона  —  автономная работа каждого микрофронтенда при получении указаний от центральной службы гипермедиа. Этот шаблон руководствуется принципами HATEOAS, то есть Hypermedia как движка состояния приложения. При этом фронтендам от бэкенда предоставляются элементы управления гипермедиа для взаимодействий.

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

Преимущества

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

Трудности

• Сложная реализация: микрофронтендов с элементами управления гипермедиа, требуется продуманный бэкенд, которым генерируются соответствующие ответы гипермедиа.
• Производительность: частые API-вызовы для извлечения элементов управления гипермедиа чреваты задержкой, что сказывается на пользовательском взаимодействии.
• Стандартизация: сложно обеспечить согласованное применение стандартов гипермедиа в приложении, требуется строгое соблюдение принципов HATEOAS.
• Обработка ошибок: создание надежных стратегий обработки ошибок для сценариев, в которых некорректно указываются ссылки или формы гипермедиа.

Сравнение шаблонов

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

Заключение

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

Главные выводы:

1. Микроприложения: обеспечиваются высокая автономность и локализация неисправностей, но для оптимизации производительности требуются тщательный контроль маршрутизации и стратегии кеширования.
2. Микрофронтенды с iFrame: обеспечиваются надежная изоляция и простота реализации, но имеются накладные расходы производительности и трудности с поддержанием целостного пользовательского взаимодействия.
3. App Shell: обеспечиваются согласованное пользовательское взаимодействие и централизованное управление общими службами, но требуются совместимые технологии и оптимизированные стратегии производительности.
4. Микрофронтенды с NPM: осуществляется модульная разработка плюс легко откатиться благодаря версионированию, но необходимы полные пересборки для обновлений и тщательный контроль зависимостей.
5. Модульная федерация: обеспечиваются гибкость времени выполнения и независимые обновления модулей, хотя требуются комплексная настройка и надежный контроль зависимостей.
6. Микрофронтенды с компонентами Bit: совершенствуются компонуемость и межкомандное взаимодействие, применяются интеграция во время сборки и во время выполнения, а также надежная визуализация зависимостей.
7. Бэкенд для микрофронтенда: соответствием служб бэкенда микрофронтендам обеспечиваются оптимизированная производительность и четкое владение, хотя при этом увеличиваются общая сложность системы и требования по ресурсам.
8. Микрофронтенды на основе порождения событий: благодаря событийно-ориентированной архитектуре обеспечиваются обновления в реальном времени и согласованное состояние, но требуются надежное хранение событий и эффективные механизмы их обработки.
9. Шаблон Hypermedia: обеспечиваются высокая гибкость и меньшая связанность плюс динамическая клиентская адаптация, обуславливаемые элементами управления гипермедиа, но сложная реализация и снижение производительности.

Сочетание шаблонов

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

Выбор правильного шаблона

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

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

Читайте также:

• Как разделить монолитное приложение на микрофронтенды
• Совместное использование кода в микросервисах и микрофронтендах: в чем разница
• Лучшие практики и инструменты для микрофронтендов

Читайте нас в Telegram, VK и Дзен

---

Перевод статьи Ashan Fernando: Mastering Micro Frontends: 9 Patterns Every Developer Should Know.