Как вы можете динамически настраивать URL-адреса для ваших объединенных удаленных модулей.
Как можно развернуть одно и то же микроинтерфейсное приложение в тестовой, промежуточной и производственной средах? Как ваше приложение может одновременно поддерживать локальное, облачное и гибридное развертывание? Как вы можете масштабировать несколько команд, работающих одновременно над разными частями архитектуры? Динамически внедрять новые удаленные приложения?
Ответ — динамически определяемые удаленные приложения.
Зачем использовать динамические пульты?
В предыдущем сообщении мы обсуждали настройку простого приложения React с использованием Webpack Module Federation в конфигурации удаленный хост. Когда мы определяли URL-адреса для удаленных приложений, мы использовали URL-адреса локального хоста:
Вышеприведенное отлично работает для локальной разработки, но это не сработает, если мы развернём и разместим приложение. Конечно, мы могли бы заменить строки рабочими URL-адресами, но что тогда произойдет с локальной разработкой? Продолжаем ли мы переключаться между ними вручную, надеясь, что никто не введет неправильные URL-адреса?
Этот шаблон также не будет работать, если у вас есть несколько этапов развертывания с разными URL-адресами и средами. Если бы мы не могли тестировать удаленные приложения в изолированных средах в конвейерах развертывания, мы столкнулись бы с хаосом и разочарованием, когда разработчики вносили бы критические изменения. Все потеряют всякую уверенность в потоке разработки.
Вместо localhostмы хотим динамически определять URL-адреса, чтобы они указывали на правильный хост в зависимости от среды.
Динамические пульты в федерации модулей Webpack
К счастью, Webpack Module Federation поддерживает динамическое определение URL-адресов для наших удаленных приложений. Мы собираемся рассмотреть четыре доступных нам решения:
- Переменные среды
- Вебпак
external-remotes-plugin - Динамические пульты на основе обещаний: docs
- Динамические удаленные контейнеры: docs
1. Переменные среды
Самый простой вариант — использовать переменные среды во время сборки. Вы можете заменить localhost в конфигурации Webpack переменными среды локально или конвейером развертывания:
Вы можете определить URL-адрес каждого удаленного приложения как локальное или размещенное производственное развертывание во время сборки. Преимущество этого подхода в его простоте, но есть проблема. Нам нужно создать новую версию для каждой среды, чтобы обновить URL-адреса. Для наших корпоративных вариантов использования и нескольких моделей развертывания это не сработает.
Что, если бы вы могли изменить удаленные URL-адреса во время выполнения?
2. Плагин внешних пультов Webpack
Под капотом Module Federation позволяет нам динамически загружать удаленные контейнеры. Мы расскажем об этом через минуту. Но сначала есть удобный плагин Webpack, разработанный Заком Джексоном, одним из создателей Module Federation, под названием external-remotes-plugin. Это позволяет нам разрешать URL-адреса во время выполнения с помощью шаблонов:
Все, что вам нужно сделать, это определить window.appAUrl и window.appBUrl в вашем приложении, прежде чем вы загрузите какой-либо код из удаленных приложений.
Теперь у вас есть возможность определять URL-адреса по своему усмотрению. Например, вы можете сохранить сопоставление URL-адресов хоста с удаленными URL-адресами для каждой среды, использовать отрисовку на стороне сервера, чтобы серверная часть могла определять URL-адреса, создать настраиваемую службу управления конфигурацией и многие другие методы.
Этот подход полностью динамичен и решит наши варианты использования, но у этого подхода все еще есть небольшое ограничение. У нас нет полного контроля над жизненным циклом загрузки.
3. Динамические пульты на основе обещаний
Федерация модулей позволяет нам определять удаленные URL-адреса как обещания, а не строки URL-адресов. Вы можете использовать любое обещание, если оно соответствует интерфейсу get/init, определенному Module Federation:
В рамках промиса мы создаем новый тег script и внедряем его в DOM, чтобы получить удаленный файл javascript. window.appAUrlсодержит URL удаленного приложения.
Удаленная конфигурация Webpack по-прежнему должна быть в строковом формате, поэтому я определил промис отдельно от конфигурации и позже преобразовал его в строку для лучшей читабельности. К сожалению, этот подход не самый простой для отладки или поддержки, потому что это строковый код внутри файла конфигурации.
До сих пор у всех подходов есть еще одно ограничение. Мы ограничены загрузкой только приложений RemoteA и RemoteB, что может быть преимуществом в плане безопасности. Но что, если разработчик работает над новым удаленным приложением, о существовании которого мы еще не знаем? Что, если партнер или клиент захочет внедрить свой удаленный модуль в свое развертывание нашего приложения?
4. Динамические удаленные контейнеры
Module Federation позволяет нам программно загружать удаленные приложения без необходимости определять какие-либо URL-адреса в нашей конфигурации Webpack:
Но как?
Подобно описанному выше подходу, прежде чем пытаться загрузить какие-либо удаленные приложения, сначала необходимо получить удаленный модуль с помощью динамического тега сценария. Затем вы можете вручную инициализировать удаленный контейнер.
container относится к удаленному приложению, которое мы настроили в поле "remotes" в конфигурации Webpack нашего хост-приложения.
module относится к одному из элементов, которые мы определили в поле "exposes" в конфигурации Webpack нашего удаленного приложения.
Используя подход внедрения тега сценария, вы можете получить удаленный контейнер и сохранить его в window.someContainer, если код разрешается в тот же шаблон get/init, который мы использовали ранее.
Если вы хотите использовать один из модулей, предоставляемых нашим удаленным приложением, все, что вам нужно сделать, это вызвать: container.get(moduleName), как в примере выше.
Как это выглядит, если вы хотите загрузить удаленное приложение React, как мы это делали в нашем базовом React host-remote app?
Посмотрите один из моих других постов для примера:
Последние мысли
Используя динамически загружаемые удаленные устройства, вы изучили четыре различных механизма, позволяющих разбить развертывание микроинтерфейса. Когда вы развертываете наш микро-интерфейс, вы можете получать удаленные приложения с любого указанного вами URL-адреса. Вы можете развернуть его в нескольких тестовых средах, локально или в облаке. Разработчики могут выбирать, использовать ли рабочие версии других удаленных приложений или динамически внедрять новые.
Какой метод вы бы выбрали?
