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

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

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

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

Преимущества микро-фронтендов

Использование архитектурного стиля микроинтерфейса имеет несколько преимуществ, в том числе:

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

Недостатки микро-фронтендов

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

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

Подходы к реализации

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

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

Состав времени сборки

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

Серверная композиция

Один из способов реализации микрофронтендов — объединить фрагменты пользовательского интерфейса на стороне сервера перед отправкой ответа в браузер. Страницы, составленные с использованием включения на стороне сервера, могут быть примером композиции на стороне сервера. Для микрофронтендов, разработанных в React или Angular, настройка может стать более сложной. В этом случае оболочка приложения будет выделенной службой, работающей на сервере, которая заботится о рендеринге компонентов пользовательского интерфейса на стороне сервера в каждом микроинтерфейсе, а затем составляется в виде одной HTML-страницы перед отправкой ответа в браузер. Этот подход более полезен, если SEO важно для вашего приложения. Одним из недостатков этого подхода является задержка, связанная с рендерингом на стороне сервера. Однако проблемы с задержкой и производительностью можно решить с помощью таких механизмов, как кэширование шаблонов.

Клиентская композиция

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

Существует несколько способов реализации композиции на стороне клиента, например с помощью iframes или таких методов, как федерация модулей. Хотя фреймы iframe могут обеспечить изолированную среду для каждого микроинтерфейса, они также могут создавать проблемы, связанные с реагированием приложений. Если вам нужно совместно использовать модули или общий код между микроинтерфейсами, лучше всего подойдет федерация модулей. На мой взгляд, Module Federation лучше подходит для реализации клиентской композиции по сравнению с iframe.

Webpack 5 поставляется с подключаемым модулем Module Federation, который упрощает реализацию микроинтерфейсов с использованием композиции на стороне клиента.

Заключение

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