Выясняем почему Angular — лучшая платформа для микро-фронтенда. Каждая растущая организация сталкивается с рядом препятствий в масштабировании продукта: перетасовка команды, выбор правильного стека технологий, несогласованность проектов и отсутствие отказоустойчивости. В современном мире мы бы начали использовать микросервисы для уменьшения зацепления приложений. Это будет идеально работать со стороны сервера, но что делать с фронтендом? Здесь в игру вступает микро-фронтенд. Давайте разберёмся, в чём преимущества и как это изменит будущее Angular. Отдельные компоненты или страницы лежат на раздельных доменах и интегрируются в основную оболочку (хост-приложение). Каждое из микро-приложений подчиняется всему бизнес-субдомену и обладает такими характеристиками:  Это не значит, что только одна команда будет ответственна за исправление всех багов. Скорее, на каждый субдомен назначается команда, которая ответственна за соответствующую предметную область бизнес-логики и стека технологий. Это даёт возможность изолировать части процесса, что, в свою очередь, позволяет прощаться с отдельными сотрудниками без ущерба для продукта и бизнеса в целом. Вы всегда обращаетесь к команде, а не к отдельному разработчику с любыми вопросами по бизнес-субдомену. Каждый из членов команды должен передавать свои личные знания остальным с помощью документирования и обменных сессий. Команда, которая отвечает за микросервис, имеет полную свободу в выборе стека технологий. Это могут быть разные фреймворки, методы кодирования или архитектура. Чем больше свободы — тем больше гибкости в работе, но мы рекомендуем кооперироваться с командами, ответственными за другие микро-приложения, как минимум в выборе фреймворка. Так вы упростите передвижение инженера между командами и получите возможность делиться и интегрировать библиотеки с виджетами, подходящими для многократного использования. Каждое из микро-приложений должно развёртываться отдельно, так как их хостят отдельные домены. Это вынуждает вас создавать множественные процессы, что иногда вызывает затруднение. Нужно внимательно следить за порядком, на случай если у нескольких микро-приложений одни и те же зависимости, либы, компоненты и ютилы. Также убедитесь в том, что ваши процессы максимально расцеплены — это позволит вам параллельно их запускать, что существенно повысит скорость работы. Микро-приложения должны быть максимально обособлены. В идеале между ними вообще не должно существовать зависимости. Они могут делить данные, например: статус, UI виджеты, интерфейсы и ютилы/хелперы через общую библиотеку. Это потребует дополнительной работы на этапе микросервисной архитектуры для создания качественной абстракции. С другой стороны, главное — не переусердствовать. Сохраняйте баланс. Одно из главных преимуществ микро-фронтенд архитектуры — надёжность. Если одно из микро-приложений ломается, другие продолжают функционировать. Это очень важно для огромных веб-приложений, где каждое микро-приложение имеет множество отдельных крупных фич. Представьте себе Facebook: если одна из фич, к примеру — сообщества, упадёт, пользователи все равно продолжат чатиться с друзьями. Какие способы внедрения микросервисной архитектуры существуют? Есть два возможных подхода: Микро-фронтенд как компонент. В этом случае микроприложение становится более детализированным. Оно начинает выполнять роль виджета, который можно повторно использовать во всех приложениях. Минус этого метода в том, что он жёстче сцепляет микро-приложения. Из-за этого могут возникать трудности с созданием абстракции, что фактически нейтрализует преимущество микросервисной архитектуры. Микро-фронтенд как страница. В этом подходе вы выделяете отдельную страницу под каждое из ваших микроприложений. Это позволяет избежать жёсткой зависимости между предками-потомками по сравнению с предыдущим подходом. В результате это самый простой способ имплементации микро-фронтенд архитектуры. Одна из сложнейших задач в архитектуре микро-фронтенда — это обмен данными. Данные могут быть различных типов, к примеру: статус, UI компоненты, сервисные функции. Убедитесь, что ваше микро-приложение не включает статусы дата-хранилища, оно должно содержаться в отдельном дата-слое, которым можно делиться. Это похоже на фронтенд — представьте бэкенд-коммуникацию, где фронтенд — это микро-приложение, а бэкенд (дата-слой) — это совместно используемая библиотека. Кроме того, UI компоненты и сервисы будут лежать в той же корзине, что и совместно используемые библиотеки. Такая концепция очень напоминает принцип работы монорепозитория. Она гарантирует последовательность между приложениями через общие данные. Есть также способы коммуникации между микро-приложениями, которые мы не можем не упомянуть. Мы можем использовать возможности хранилища нашего браузера. Это могут быть localStorage, sessionStorage, cookies для хранения данных о сессиях или метаданных юзеров, а также более сложные структурные данные в indexedDB. Кроме того, вы можете просто настроить передачу данных между микро-приложениями через параметры строки запроса. 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 добавить её поддержку в новых версиях, а также ставьте лайки и комментируйте, если узнали что-то новое.    SMM,