5 причин перехода к микрофронтенд архитектуре
2 года назад·4 мин. на чтение
Микрофронтенды — это применение микросервисной архитектуры к фронтенд приложениям. Преобразование приложения монолита из одного большого приложения в приложение, объединяющее несколько небольших UI приложений.
Независимые команды разработки
Если вы работаете в нескольких командах, организационные накладные расходы становятся значительными. Общение должно происходить хотя бы ежедневно. Согласование, необходимое для управления разработкой и развертыванием, становится невозможным. Благодаря микрофронтендам управление масштабируемостью с точки зрения ресурсов разработки становится намного проще. Как правило, каждая функция может быть разработана независимой командой. Каждая команда может автономно публиковать свой функционал без какого-либо согласования. Некоторые подходы к микрофронтендам требуют, по крайней мере, общей системы сборки или общего уровня (например, reverse proxy). Хотя такие вещи все еще можно решить заранее, они делают все решение более сложным, чтобы его можно было правильно настроить на начальном этапе. Поэтому рекомендуется искать решения, которые уже работают после первоначальной настройки.Более быстрое время выхода на рынок (TTM, Time To Market)
Независимая природа микрофронтендов также влияет на время выхода отдельных функций на рынок. Пока монолит будет развиваться все медленнее и медленнее, микрофронтенд будет идти в ногу со временем. Естественно, здесь тоже потребуется рефакторинг и улучшение базовой технологии, однако темпы цикла, описанного ниже, для каждой новой фичи будут быстрее.- начать новый проект
- разработать MVP
- зарелизить MVP
- пройтись по MVP (доработать и зарелизить)
- перейти в режим обслуживания
Фича флаги (Feature Flags)
Замечательно иметь отдельные микрофронтенды, составляющие вместе одно приложение. Но довольно часто владельцы продуктов хотят выйти за рамки технической композиции: они хотят использовать модульность также и для бизнес-целей. Случалось ли вам когда-нибудь, что определенная функциональность должна быть доступна только определенным пользователям? Функции администратора должны быть доступны только администраторам. Хотя UI не следует использовать в качестве уровня защиты (эти проверки осуществляются на бэкэнде), мы также не хотим показывать вещи, которые нельзя (или не следует) использовать. Следовательно, мы добавим в наш код такие вещи, как:if (hasFeature('foo')) { // ... }
foo
верно для всех? Что делать, если функция деактивирована для всех? Что, если завтра появится новое условие, изменяющее некоторые части, чтобы также оценить, включена ли переменная bar
?
Поскольку у нас уже есть надлежащая модульность, довольно просто добавить фича флаги. Все, что нам нужно сделать, это ввести условный рендеринг модуля (или его загрузки) с помощью флагов. Никаких изменений кода на функциональном уровне модуля.
Хотя подобные вещи могут работать и в классических монолитах, они требуют дополнительных усилий по реализации. С микрофронтендами архитектура уже полностью к этому готова.
Единая ответственность
Несмотря на то, что микросервисы не являются решением для всего, они преподносятся как таковые. Да, они, безусловно, являются хорошим решением во многих (или даже в большинстве) случаях, но очень часто монолит или другая форма сервис-ориентированной архитектуры может оказаться не менее хорошим решением. Тем не менее, наличие выделенного сервиса (с ответственной за него командой) в бэкенде — хорошее начало. Замена монолита различными микрофронтендами — это отличное продолжение, поскольку можно ввести дополнительное измерение для разделения команд.Свобода технологий
За последние два года фронтенд-технология в значительной степени стабилизировалась. Хотя и появляются новые подходы, например Svelte, которые бросают вызов таким библиотекам как React, но все же серьезных преимуществ они не предлагают. Часто существует несколько подходов и не существует универсального решения. В микрофронтенд приложениях все разные приложения могут работать вместе. Страница, написанная с помощью Angular, может использовать компонент из микрофронтенда React и наоборот. Модальное диалоговое окно для сохранения пользовательских данных может быть написано на Vue, а компонент под ним — на Svelte.- Мы разделяем только CSS?
- Как насчет поведения?
- Являются ли веб-компоненты решением для этого?
Итоги
Микрофронтенды — это не панацея. Они могут помочь и обеспечить ценность, когда обстоятельства благоприятны. Если ни одна из вышеперечисленных причин не имеет для вас никакого значения, велика вероятность, что вам не нужно внедрять микрофронтенд архитектуру.Микрофронтенд и Module Federation
2 года назад·6 мин. на чтение
Module Federation - это плагин для Webpack. С его помощью можно разбивать приложение на микрофронтенды, подключив их в хост приложение.
Здесь микрофронтенды - это несколько отдельных сборок. Вместе они формируют одно приложение. Эти отдельные сборки действуют как контейнеры и могут предоставлять и использовать код между сборками, создавая единое унифицированное приложение.
Динамический
Установка
Можно разрешить хосту задавать
Вывод
Можно вывести
Низкоуровневые концепции
Различаются два вида модулей - локальные и удаленные модули. Локальные модули — это обычные модули, которые являются частью текущей сборки. Удаленные модули (remote modules) — это модули, которые не являются частью текущей сборки, но загружаются во время выполнения из удаленного контейнера. Загрузка удаленных модулей считается асинхронной операцией. Невозможно использовать удаленный модуль без загрузки его чанка. Операция загрузки чанка обычно является вызовомimport()
, но также поддерживаются более старые конструкции, такие как require.ensure
или require([...]))
.
Контейнер создается с помощью точки входа контейнера, которая предоставляет асинхронный доступ к определенным модулям. Доступ к предоставляемым (expose) моделям разделен на два этапа:
- загрузка модуля (асинхронная)
- выполнение модуля (синхронная).
Высокоуровневые концепции
Каждая сборка действует как контейнер, а также потребляет другие сборки в качестве контейнеров. Таким образом, каждая сборка может получить доступ к любому другому предоставленному модулю, загрузив его из своего контейнера. Общие модули — это модули, которые являются переопределяемыми и предоставляются в качестве переопределений для вложенных контейнеров. Они обычно указывают на один и тот же модуль в каждой сборке, например, на одну и ту же библиотеку. ПараметрpackageName
позволяет задать имя пакета для поиска requiredVersion
. Он автоматически выводится для запросов модуля по умолчанию. Установите requiredVersion
в false
, когда автоматический вывод должен быть отключен.
Основные части
ContainerPlugin (низкий уровень)
Этот плагин создает дополнительную запись контейнера с указанными открытыми модулями.ContainerReferencePlugin (низкий уровень)
Этот плагин добавляет конкретные ссылки на контейнеры как внешние и позволяет импортировать удаленные модули из этих контейнеров. Он также вызывает APIoverride
этих контейнеров для предоставления им переопределений. Локальные переопределения (через __webpack_override__
или override
API когда сборка является контейнером) и указанные переопределения предоставляются всем контейнерам, на которые имеются ссылки.
ModuleFederationPlugin (высокий уровень)
ModuleFederationPlugin
объединяет ContainerPlugin
и ContainerReferencePlugin
.
Какие цели преследует Module Federation
- Должна быть возможность предоставлять и использовать любой тип модуля, поддерживаемый webpack.
- При загрузке чанков должно загружаться все необходимое параллельно (за один запрос к серверу).
- Управление от потребителя к контейнеру
- Переопределение модулей представляет собой однонаправленную операцию.
- Родственные контейнеры не могут переопределять модули друг друга.
- Концепция должна быть независимой от среды.
- Можно использовать в web, Node.js и т. д.
- Относительный и абсолютный запрос в
shared
:- Всегда будет предоставлен, даже если не используется.
- Будет разрешаться относительно
config.context
. - Не использует
requiredVersion
по умолчанию.
- Запросы модулей в
shared
:- Предоставляются только тогда, когда они используются.
- Будет соответствовать всем используемым равным запросам модулей в вашей сборке.
- Предоставит все соответствующие модули.
- Будет извлекать
requiredVersion
изpackage.json
в этой позиции в графе. - Может предоставлять и использовать несколько различных версий при наличии вложенных
node_modules
.
- Запросы модулей с
/
вshared
будут сопоставлять все запросы модулей с этим префиксом.
Примеры использования
Отдельные сборки для каждой страницы
Каждая страница одностраничного приложения предоставляется из контейнерной сборки в отдельной сборке. Оболочка приложения (application shell) также представляет собой отдельную сборку, ссылающуюся на все страницы как на удаленные модули. Таким образом, каждая страница может быть развернута отдельно. Оболочка приложения заново развертывается при обновлении маршрутов или добавлении новых маршрутов. Оболочка приложения определяет часто используемые библиотеки как разделяемые модули (shared), чтобы избежать их дублирования в сборках страниц.Библиотека компонентов в качестве контейнера
Многие приложения имеют общую библиотеку компонентов, которая может быть построена как контейнер с каждым отдельным компонентом. Каждое приложение использует компоненты из контейнера библиотеки компонентов. Изменения в библиотеке компонентов можно развертывать отдельно без необходимости повторного развертывания всех приложений. Приложение автоматически использует обновленную версию библиотеки компонентов.Динамические удаленные контейнеры
Интерфейс контейнера поддерживает методыget
и init
. init
— это async
метод, который вызывается с одним аргументом: объектом общей области (shared scope). Этот объект используется в качестве общей области в удаленном контейнере и заполняется предоставленными модулями от хоста. Его можно использовать для динамического подключения удаленных контейнеров к контейнеру хоста во время выполнения.
Контейнер пытается предоставить общие модули, но если общий модуль уже использовался, предупреждение и предоставленный общий модуль будут проигнорированы. Контейнер может по-прежнему использовать его в качестве запасного варианта. Таким образом, вы можете динамически загружать A/B-тест, который предоставляет другую версию общего модуля. Убедитесь, что контейнер загружен, прежде чем пытаться динамически подключить удаленный контейнер. Пример:// init.js (async () => { // Инициализирует общую область. Заполняет его предоставленными модулями // из текущего билда и из удаленных билдов await __webpack_init_sharing__('default'); const container = window.someContainer; // или получить контейнер откуда-либо еще // Проинициализируйте контейнер, он может предоставлять общие модули await container.init(__webpack_share_scopes__.default); const module = await container.get('./module'); })();
// init.js function loadComponent(scope, module) { return async () => { // Инициализирует общую область. Заполняет его предоставленными модулями // из текущего билда и из удаленных билдов await __webpack_init_sharing__('default'); const container = window[scope]; // или получить контейнер откуда-либо еще // Проинициализируйте контейнер, он может предоставлять общие модули await container.init(__webpack_share_scopes__.default); const factory = await window[scope].get(module); const Module = factory(); return Module; }; } loadComponent('abtests', 'test123');
Динамические удаленные модули на основе промисов
Как правило, удаленные модули настраиваются с использованием URL-адресов, как в этом примере:Но вы также можете передать промис в этот модуль, который будет зарезолвлен во время выполнения. Вы должны зарезолвить этот промис с помощью любого модуля, который соответствует интерфейсуmodule.exports = { plugins: [ new ModuleFederationPlugin({ name: 'host', remotes: { app1: 'app1@http://localhost:3001/remoteEntry.js', }, }), ], };
get
/init
, описанному выше. Например, если вы хотите передать, какую версию fedarated модуля вы должны использовать, с помощью параметра запроса вы можете сделать что-то вроде следующего:
Обратите внимание, что при использовании этого API необходимо зарезолвить объект, содержащий APImodule.exports = { plugins: [ new ModuleFederationPlugin({ name: 'host', remotes: { app1: `promise new Promise(resolve => { const urlParams = new URLSearchParams(window.location.search) const version = urlParams.get('app1VersionParam') // Эта часть зависит от того как вы планируете хостить // и версионировать ваши federated модули const remoteUrlWithVersion = 'http://localhost:3001/' + version + '/remoteEntry.js' const script = document.createElement('script') script.src = remoteUrlWithVersion script.onload = () => { // внедренный скрипт загружен и доступен через объект window // теперь можно зарезолвить Promise const proxy = { get: (request) => window.app1.get(request), init: (arg) => { try { return window.app1.init(arg) } catch(e) { console.log('remote container already initialized') } } } resolve(proxy) } // внедрим этот скрипт с src с версионированным remoteEntry.js document.head.appendChild(script); }) `, }, // ... }), ], };
get
/init
.
Динамический publicPath
Установка publicPath
Можно разрешить хосту задавать publicPath
удаленного модуля во время выполнения, предоставляя метод из этого удаленного модуля.
Этот подход особенно полезен при подключении независимо развернутых дочерних приложений по подпути домена узла.
Сценарий:
У вас есть хост приложение, размещенное на https://my-host.com/app/*
, и дочернее приложение, размещенное на https://foo-app.com
. Дочернее приложение также монтируется на хост-домене, следовательно, ожидается, https://foo-app.com
будет доступно через https://my-host.com/app/foo-app
, а запросы https://my-host.com/app/foo-app/*
перенаправляются https://foo-app.com/*
через прокси-сервер.
Пример:
// webpack.config.js (удаленный) module.exports = { entry: { remote: './public-path', }, plugins: [ new ModuleFederationPlugin({ name: 'remote', // это имя должно совпадать с именем точки входа exposes: ['./public-path'], // ... }), ], };
public-path.js (remote) export function set(value) { __webpack_public_path__ = value; }
// src/index.js (host) const publicPath = await import('remote/public-path'); publicPath.set('/your-public-path'); //bootstrap app e.g. import('./bootstrap.js')
Вывод publicPath
из скрипта
Можно вывести publicPath
из тега script
из document.currentScript.src
и задать его с переменной __webpack_public_path__
во время выполнения.
Пример:
// webpack.config.js (удаленный) module.exports = { entry: { remote: './setup-public-path', }, plugins: [ new ModuleFederationPlugin({ name: 'remote', // this name needs to match with the entry name // ... }), ], };
Существует также значениеsetup-public-path.js (удаленный) // вычислите publicPath и установите его в __webpack_public_path__ __webpack_public_path__ = document.currentScript.src + '/../';
'auto'
, доступное для output.publicPath
, которое автоматически определяет publicPath
для вас.