Выясняем почему Angular — лучшая платформа для микро-фронтенда.

Вступление

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

Давайте разберёмся, в чём преимущества и как это изменит будущее Angular.

Для чего нужен микро-фронтенд?

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

Подчинение одной команде

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

Независимая имплементация

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

Независимое развёртывание

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

Обособление

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

Отказоустойчивость

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

Надёжная микро-фронтенд архитектура

Какие способы внедрения микросервисной архитектуры существуют? Есть два возможных подхода:

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

• Микро-фронтенд как страница. В этом подходе вы выделяете отдельную страницу под каждое из ваших микроприложений. Это позволяет избежать жёсткой зависимости между предками-потомками по сравнению с предыдущим подходом. В результате это самый простой способ имплементации микро-фронтенд архитектуры.

 Способы передачи данных между микроприложениями

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

Есть также способы коммуникации между микро-приложениями, которые мы не можем не упомянуть. Мы можем использовать возможности хранилища нашего браузера. Это могут быть localStorage, sessionStorage, cookies для хранения данных о сессиях или метаданных юзеров, а также более сложные структурные данные в indexedDB. Кроме того, вы можете просто настроить передачу данных между микро-приложениями через параметры строки запроса.

Почему Angular?

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

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

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

Функция маршрутизации идёт вместе с Angular OOB, и вам не нужно устанавливать никакие внешние доп. пакеты. Платформа даёт вам всё, что необходимо для перемещений между микро-приложениями. Элементы router outlet позволят вам создать основную оболочку и хостить навигацию каждой страницы микро-приложения. Вы также можете выбирать, какой из элементов будет грузить тот или иной angular-модуль.

И, наконец, «ленивая загрузка», которая подгружает angular-модуль только тогда, когда он нужен, уменьшая размер пакета приложения и ускоряя загрузку страницы. У Angular есть нативная интеграция между модулями маршрутизации и ленивой загрузки. Единственное ограничение — он должен грузиться за время компиляции, но нам нужно, чтобы модули грузились динамично, за время прогона. Чуть позже мы покажем вам, как это делать.

Как собирать код?

Мы изучили лучшие подходы микро-фронтенда и выяснили, как angular соотносится с применением такой архитектуры, но осталось несколько слепых зон.

Первое, как подгружать модули динамично, в реальном времени? Эта проблема с лёгкостью решается плагином Module Federation, который идёт вместе с веб-пакетом. Он поддерживает локальные и удалённые модули для независимой и асинхронной сборки, что оптимально для нашего случая.

Второй вопрос: как объединять все эти источники для создания рабочего прототипа, который можно перебирать? Самый быстрый способ — использовать NX cli, который будет генерировать для нас шаблонные коды. Для того чтобы узнать больше, взгляните на наш пошаговый туториал по сборке микро-фронтенда с angular, расшаром NgRx статуса и использованием командной строки NX.

Заключение

Мы узнали, что микро-фронтенд архитектура отлично ложится на Angular. Существует ряд инструментов для их объединения, таких как Module Federation и NX монорепозитории. Мы можем только предполагать, будет ли Angular поддерживать микро-фронтенд архитектуру OOB в будущем.

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