Возможно, вы слышали о модных словах «Module Federation», «Micro frontend», и если вы новичок в Module Federation, вы можете просмотреть эту историю, поскольку я буду разрабатывать эту концепцию самым простым, но эффективным и простым способом, как я люблю, "Откровенный разговор, никакой чепухи". Я буду обсуждать:
- Что такое федерация модулей?
- Почему он существует?
- Как этого можно достичь?
ЧТО: Module Federation — это архитектура JavaScript, придуманная Заком Джексоном, которая дает нам метод совместного использования кода между внешними приложениями во время выполнения. Основная идея состоит в том, чтобы разделить большое приложение на маленькие части.
Первоначально, когда я усваивал эту идею, она звучала знакомо с npm, т.е. диспетчером пакетов Node, это наиболее распространенный способ обмена кодом JavaScript, поэтому я искал их различия, их плюсы и минусы, и я обнаружил, что:
- В пакете NPM нет кода рендеринга.
- Это увеличивает размер приложения по мере того, как вы добавляете все больше и больше пакетов, а также увеличивает время развертывания.
- Изменение версии является большой проблемой при таком подходе.
Но клиент или покупатель может быть заинтересован или не заинтересован в наличии микро-приложения для своего продукта, скорее клиент будет требовать единое консолидированное приложение, поэтому мы можем сказать, что это будет абстракция для конечного пользователя и будет представлена пользователя как одностраничное приложение.
Микрофронтенд — это основная концепция федерации модулей, мы можем сказать, что федерация модулей построена с использованием микрофронтендов.
Они могут быть:
- Запускать на разных портах.
- Разные папки, разные источники, разные репозитории.
- У них разные версии с разными технологиями; например, некоторые созданы на Angular, некоторые на React, некоторые на Vue и т. д.
ПОЧЕМУ: это может быть полезно во многих случаях, например:
- Он будет содержать меньший и более оптимизированный размер пакета, он обеспечивает в целом лучший опыт для разработчиков и пользователей благодаря общим компонентам и зависимостям, которые можно лениво загружать, когда мы захотим.
- Было бы полезно разделить, когда продукт слишком велик, чтобы его можно было обрабатывать, имея в нем разные модули с разными концепциями.
- Одним из больших преимуществ является возможность для групп разработчиков, разбросанных по разным местам и работающих над конкретным продуктом, выбирать технологический стек по своему выбору, не опасаясь несовместимости с другим кодом.
Они разделены на одну оболочку и удаленные приложения. Shell — это, по сути, приложение для мейнфреймов, отвечающее за части небольших приложений, которые должны быть извлечены по запросу.
Мы можем разбить огромное приложение, разделив его на:
СТРАНИЦА: прерывание одновременного запуска разных страниц, поскольку это может привести к сбою приложения на старых устройствах.
ФУНКЦИОНАЛЬНОСТЬ: разделение нескольких сложных функций с разными концепциями на несколько приложений.
РАЗДЕЛ: разбивка приложений по разделам, при этом разные приложения используют один и тот же раздел или компоненты.
КАК:использование Angular 12 и Webpack 5
Предварительные требования:
• Угловой интерфейс командной строки: ›= 11.2.8
• Узел: ›= 15.4.0
• Веб-пакет: ›= 5.4.0
Пакет модуль-федерация Angular Architects: пакет, который используется для реализации интеграции модулей, который в основном создает простой API для запроса модулей или, можно сказать, приложений микроинтерфейса, и загружает их в наше приложение оболочки.
ng add @angular-architects/module-federation — оболочка проекта — порт 5000
Нам нужно запустить эту команду в оболочке и удаленных приложениях с правильным именем проекта и уникальным портом.
Приведенная выше команда вносит несколько внутренних изменений и добавляет файл webpack.config для конфигураций, связанных с объединением модулей. Это в дополнение к угловым конфигурациям.
У нас также могут быть общие пакеты или общие модули, чтобы у нас не было дубликатов и пакетов с несоответствием версий. Но основная часть — это предоставление имени, имени файла и раскрытие модуля. Сопоставление выполняется по имени файла, в данном случае remoteEntry.js — это небольшой файл, который создается во время выполнения. В приложении Shell мы определяем ключи для доступа к файлам remoteEntry, чтобы Angular знал, откуда лениво загружать модуль.
Все эти приложения являются двунаправленными хостами. что означает, что любое приложение, которое загружается первым, становится хостом — при изменении маршрутов будут соответственно загружены федеративные модули.
Здесь, чтобы получить модуль, мы в основном используем вспомогательный метод из пакета, который мы добавили ранее, под названием loadRemoteModule, где мы передаем правильное значение remoteName, remoteEntry иposedModule, которые мы использовали в файле webpack.config.js удаленных приложений.
Я видел этот пример, который кажется наиболее подходящим для этой концепции, который показывает, что есть 4 модуля, которые можно разбить на определенные приложения, основанные на различных функциях внутри него, разработанных на разных языках.
ЗАКЛЮЧЕНИЕ:
Итак, из этой истории мы можем сделать вывод, что следует или не следует внедрять микрофронтенды, зависит от типа проекта, который вы создаете, потому что этот подход не будет лучшим для небольших приложений или предприятий. Архитектурный подход с микроинтерфейсом лучше всего подходит при работе над большим проектом с распределенными командами.
Для подтверждения концепции: см. мой созданный пример, иллюстрирующий эту концепцию.
Шаги по настройке:
- Запустите npm install: для установки зависимостей.
- Запустите приложение Micro Frontend 1:
нг служить mfe1 -o
- Запустите приложение Micro Frontend 2:
нг служить mfe2 -o
- Запустить приложение оболочки:
ng подавать оболочку -o
(где флаги o говорят об открытии приложения в браузере по умолчанию).
