Микрофронтенды

Вольный перевод статьи Micro-frontends in context

Когда и почему разработчикам следует рассмотреть этот новый, меньший по размеру архитектурный паттерн фронтенда?

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

Обычно, вы создаете MVP (minimum viable product), чтобы как можно быстрее собрать данные напрямую от ваших пользователей. Вам нужно разработать архитектуру и выбрать базу данных, SQL или NoSQL, в зависимости от потребностей вашего продукта. Возможно, вы затем создадите монолит для уровня API, чтобы минимизировать накладные расходы на несколько конвейеров CI / CD, и настроите рекомендуемые observability инструменты. Вы сосредоточитесь на бизнес-логике приложения и, что не менее важно, создадите приложение на стороне клиента, возможно, используя хорошо известный фреймворк, такой как Vue, Angular или React. Если вам повезет, через несколько месяцев у вас будет готовый продукт и много пользователей, подписавшихся на сервис.

Допустим, этот проект действительно успешный, и компания решает инвестировать в него и дальше. Чтобы поддержать эту работу, вам придется нанять больше людей. Внезапно вы обнаруживаете, что у вас гораздо больше разработчиков, чем было вначале. Глядя на dashboard, вы также понимаете, что некоторые API используются совершенно иначе, чем вы планировали изначально. Некоторые из них хорошо кэшируемы, поэтому CDN принимает на себя основной удар; другие напрямую обращаются к вашему бэкэнду тысячи раз в секунду.

Масштабирование всего монолита по горизонтали не взлетит в этой вселенной. (Есть риск масштабировать все API вместо тех, которые вам действительно нужны, что может привести к таким проблемам, как узкие места с пропускной способностью или трудности с поддержанием кодовой базы в такой большой команде.) Итак, что вы собираетесь делать?

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

Для многих проектов интерфейс остается неизменным: одностраничное приложение (SPA) и / или server side rendering приложение, которое просто растет и растет с каждой новой фичей, добавляемой к платформе. В этом сценарии распределенные команды, вероятно, работают над одной и той же кодовой базой, наследуя решения, принятые горсткой людей, начавших проект в совершенно другом контексте. Но фронтенд команды сталкиваются с теми же проблемами организации и масштабируемости, что и бэкэнд команды. Разве у них или у вас - есть другие варианты?

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

Некоторые аспекты микрофронтенда

Моделирование микрофронтендов вокруг бизнес составляющих

Моделирование микрофронтендов на основе принципов Domain Driven Design (DDD) возможно и ценно для структурирования масштабируемой организации и создания эффективных автономных команд. Хотя DDD традиционно обеспечивает четкое руководство для управления бэкэнд-проектами, некоторые из этих практик могут также использоваться во фронтенде. Если вы потратите время в начале проекта на определение ваших бизнес-областей и решение, как разделить приложение, это поможет вам сформировать свои команды, очертить границы доменов вашего проекта и создать универсальный язык между командами.

Культура автоматизации

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

Скрытие деталей реализации

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

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

Децентрализация

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

Независимые деплои

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

Фреймворк решений для микрофронтендов

Как вы можете применить архитектуру микрофронтендов к новому или существующему проекту? Ваш подход будет зависеть от вашего рабочего контекста.

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

Определение микрофронтендов

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

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

Выбор вертикального разделения означает, что вы будете смотреть на одну и ту же проблему с точки зрения бизнеса, а не с технической точки зрения. Вы назначите команде каждый бизнес-домен, например пользовательский интерфейс аутентификации или пользовательский интерфейс каталога. Это позволяет каждой команде стать экспертами в предметной области, что, как я отмечал ранее, особенно ценно, когда у команд есть больше агентств, которые могут использовать этот опыт. Фактически, каждая команда домена, независимо от того, из скольких представлений (view) состоит домен, может работать полностью автономно.

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

Составление микрофронтендов

Есть три способа составить архитектуру микрофронтендов:

• Клиентская композиция
• Боковая композиция
• Серверная композиция

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

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

В этом паттерне архитектуры приложение загружает несколько микрофронтендов непосредственно из CDN (или из источника, если микрофронтенды еще не кэшированы на уровне CDN), часто с помощью JavaScript или HTML-файла в качестве входной точки для микрофронтенда. Таким образом, приложение может динамически добавлять узлы DOM (в случае файла HTML) или инициализировать приложение JavaScript (если точкой входа является файл JavaScript).

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

Пограничная композиция

Пограничная композиция собирает view на уровне CDN, извлекая ваши микрофронтенды из источника и доставляя конечный результат клиенту. Многие поставщики CDN позволяют использовать Edge Side Includes (ESI), язык разметки на основе XML. ESI был введен для поддержки возможности масштабирования веб-инфраструктуры за счет использования большого количества точек раздачи по всему миру, предоставляемых сетью CDN. Однако ESI не реализуется одинаково внутри каждого провайдера CDN, что усложняет его использование. Использование стратегии мульти-CDN или простая смена провайдеров может привести к множеству рефакторов и новой логике для реализации.

Поскольку включение на уровне CDN не имеет смысла при вертикальном разделении, этот подход работает только с горизонтальным разделением. Боковая композиция наиболее полезна на статических страницах, которые необходимо масштабировать, но при этом не требуется контроля над каждой деталью - подумайте о новостных веб-сайтах и ​​онлайн-каталогах, таких как Ikea, которые сочетают edge-side includes и client-side includes. CDN заботится об аспекте масштабируемости окончательного решения и будет обслуживать пользователя с максимально ближней точки.

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

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

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

Роутинг микрофронтендов

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

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

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

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

Взаимодействие между микрофронтендами

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

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

Если вы работаете с вертикальным разделением, вам нужно понимать, как делиться информацией между микрофронтендами. Как для горизонтального, так и для вертикального подходов подумайте о том, как представления взаимодействуют при изменении. Возможно, переменные могут быть переданы через строку запроса или с помощью URL-адреса для передачи небольшого количества данных. В качестве альтернативы вы можете использовать веб-хранилище для временного (session storage) или постоянного (local storage) информации, которая будет использоваться другими микрофронтендами.

Погрузитесь в микромир

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

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