Зачем переходить на микрофронтенды

Проблемы монолита

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

• каталог товаров,
• профиль пользователя,
• корзина,
• управление заказами,
• обработка платежей.

Так выглядит интерфейс онлайн-магазина «Шайба». Фронтенд состоит из двух страниц: на первой три раздела, на второй — два.

• Темп разработки замедлился. С ростом приложения кодовая база фронтенда растёт, а частота релизов падает: чтобы добавить функцию или исправить ошибку, нужно понимать устройство всего приложения. Онбординг новых сотрудников занимает всё больше времени — приходится рассказывать массу нюансов.
  Пример. На страницу листинга товаров решили добавить опцию фильтра. Для этого пришлось внести изменения в несколько частей монолитной кодовой базы: скорректировать API бэкенда, изменить логику фронтенда и обновить систему управления состоянием. Взаимозависимость этих элементов замедлила процесс внедрения функции — пришлось координировать действия двух команд.
• Любое обновление сопряжено с рисками. Все компоненты приложения тесно связаны между собой, поэтому обновления становятся рискованными. Небольшое изменение в одной части приложения может привести к непредвиденным ошибкам в другой. Даже если номинально они не связаны между собой.
  Пример. Незначительное обновление интерфейса обработки платежей изменило макет страницы профиля пользователя. Это произошло из-за общих файлов CSS и JavaScript. Изменение привело не только к визуальным регрессиям, но и к функциональным ошибкам. Это понизило удовлетворённость и доверие пользователей.
• Сложно масштабироваться. Чтобы масштабировать отдельные функции, нужно масштабировать всё приложение.
  Пример. Во время акции «Чёрная пятница» выросла нагрузка на каталог товаров и системы оформления заказа. Чтобы справиться с потоком заказов, «Шайбе» пришлось масштабировать весь фронтенд. При этом нагрузка на другие разделы — например, на управление профилем пользователя — не изменилась.

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

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

• одна работает над корзиной;
• вторая — над каталогом товаров;
• третья — над профилем пользователя;
• четвёртая — над управлением заказами;
• пятая — над обработкой платежей.

Основные преимущества микрофронтендов

1. Повышение организационной гибкости

2. Можно выбрать несколько технологических стеков

3. Упрощение управления кодом

4. Более управляемое масштабирование

5. Повышение отказоустойчивости

6. Ускорение времени выхода на рынок

Как устроена архитектура микрофронтенда

1. Модули микрофронтенда. Это основные элементы архитектуры. Каждый модуль — это определённая бизнес-область или функциональность. Модули разрабатывают, тестируют и развёртывают независимо друг от друга.
2. Слой композиции. Он отвечает за сборку различных модулей микрофронтенда в целостное приложение, а также управляет потоком данных и взаимодействием между клиентом и сервером. Компоновка модулей может происходить на стороне сервера, на стороне клиента или с помощью гибридного подхода. Выбор подхода зависит от потребностей и ограничений приложения.
3. Маршрутизация. При работе с микрофронтендами важно выбрать эффективные механизмы маршрутизации. Надо гарантировать, что запросы будут направляться к нужному микрофронтенду. Это поможет сохранить модульность приложения и при этом обеспечить плавную навигацию для пользователей. Если маршрутизация продумана плохо, микрофронтенды будут зависеть друг от друга. Как итог — все преимущества архитектурного стиля сойдут на нет.
4. Коммуникационный слой. Этот слой управляет взаимодействием между микрофронтендами и остальной инфраструктурой приложения. Реализовать коммуникацию можно через API, шины сообщений или собственные системы событий.

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

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

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

Слой композиции

• Серверная компоновка. Здесь реализовали Backend for Frontend (англ. «бэкенд для фронтенда», BFF). Про этот подход будет отдельный урок. Если кратко, BFF — это специализированный API, который перенаправляет запросы от микрофронтенда бэкенду. У каждого микрофронтенда свой BFF. Серверная часть обрабатывает все данные, взаимодействует с API и при необходимости предоставляет клиенту предварительно отрендеренный HTML. Это полезно для начальной загрузки страниц и SEO — гарантирует, что сервер предоставит клиенту полностью сформированную страницу.
• Клиентская компоновка. После первоначальной загрузки страницы клиентская сторона берёт на себя динамические взаимодействия, для которых необязательно обращаться к серверу. В этом случае JavaScript-фреймворки и библиотеки управляют обновлениями DOM, состоянием клиента и рендерингом на основе взаимодействия с пользователем. Клиентская компоновка гибкая и позволяет создавать высокоинтерактивные веб-приложения.

Маршрутизация

• Гибридный подход к маршрутизации. Он сочетает механизмы маршрутизации на стороне сервера и на стороне клиента:
  • Маршрутизацию на стороне сервера используют для начальной загрузки страниц, чтобы оптимизировать их для SEO и ускорить время рендеринга.
  • Клиентскую маршрутизацию используют во время взаимодействия с пользователем. Это обеспечивает плавные переходы и динамическое обновление контента без полной перезагрузки страницы.
• Динамическая обработка маршрутов:
  • У каждого микрофронтенда свой маршрутизатор. Команды могут управлять логикой маршрутизации для своих разделов.
  • Центральный оркестратор динамически загружает нужный микрофронтенд в зависимости от навигации пользователя. Оркестратор использует маршрутизатор на основе JavaScript для интерпретации URL-адреса и получения нужного микрофронтенда.

...

registerApplication({
  name: 'product-list',
  app: () => System.import('productList'),
  activeWhen: ['/products']
});

registerApplication({
  name: 'user-profile',
  app: () => System.import('userProfile'),
  activeWhen: ['/profile']
});

registerApplication({
  name: 'checkout',
  app: () => System.import('checkout'),
  activeWhen: ['/checkout']
});

... 

Коммуникационный слой

Когда микрофронтенды — не лучшее решение

1. Приложение маленькое или простое

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

2. Ресурсы разработки ограничены

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

3. Компоненты тесно связаны

• Высокая взаимозависимость. Если компоненты приложения тесно связаны между собой, разделить их на микрофронтенды будет сложно и рискованно. Рефакторинг приложения потребует столько усилий, что не оправдает себя.
• Глобальное состояние и зависимости. Если приложение сильно зависит от глобального состояния (global state) и глобальных зависимостей, будет трудно поддерживать согласованность между микрофронтендами. Переход создаст больше проблем, чем решит.

4. У вас краткосрочный проект или прототип

• Время ограничено. Первоначальная установка и настройка архитектуры микрофронтендов может отнять много времени. Это не подходит краткосрочным проектам, прототипам и приложениям с жёсткими сроками. Здесь лучше использовать монолитный подход — он обеспечит быструю разработку и быстрые итерации на старте.
• Вы разрабатываете PoC (Proof Of Concept) или MVP (Minimum Viable Product). Доказательства концепции и минимально жизнеспособные версии продукта помогают быстро проверить идеи и собрать отзывы. Им подойдёт более простая архитектура.

5. У вас жёсткие требования к производительности

• Вам важна производительность на стороне клиента. Микрофронтенды повышают накладные расходы: использование микрофреймворков фронтенда (например, Single SPA) и динамической загрузкой модулей (например, Webpack Module Federation) могут влиять на производительность. Если вы предъявляете жёсткие требования к производительности приложения, лучше оптимизировать монолит, а не делить его на микрофронтенды. Особенно если вам важна производительность на стороне клиента.

6. В компании есть организационное или культурное сопротивление

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

7. Инфраструктура и инструментарий ограничены

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

Итоги

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

Что ещё почитать про микрофронтенды?

• Статья Майкла Гирса, автора книги «Микрофронтенды в действии»
• Пример онлайн-магазина — идеи из книги со ссылками на GitHub