Frontend Micro-Frontend: Освоение архитектуры Module Federation

В современном быстро развивающемся ландшафте веб-разработки построение и поддержка крупномасштабных frontend-приложений может становиться все более сложной задачей. Традиционные монолитные архитектуры часто приводят к таким проблемам, как раздувание кода, медленное время сборки и трудности с независимыми развертываниями. Micro-frontends предлагают решение, разбивая frontend на более мелкие, более управляемые части. Эта статья углубляется в Module Federation, мощную технику для реализации micro-frontends, исследуя ее преимущества, архитектуру и практические стратегии реализации.

Что такое Micro-Frontends?

Micro-frontends — это архитектурный стиль, при котором frontend-приложение декомпозируется на более мелкие, независимые и развертываемые единицы. Каждый micro-frontend обычно принадлежит отдельной команде, что обеспечивает большую автономию и более быстрые циклы разработки. Этот подход отражает архитектуру микросервисов, обычно используемую на backend.

Ключевые характеристики micro-frontends включают:

• Независимая развертываемость: Каждый micro-frontend может быть развернут независимо, не затрагивая другие части приложения.
• Автономия команды: Разные команды могут владеть и разрабатывать разные micro-frontends, используя предпочитаемые ими технологии и рабочие процессы.
• Технологическое разнообразие: Micro-frontends могут быть созданы с использованием различных фреймворков и библиотек, позволяя командам выбирать лучшие инструменты для работы.
• Изоляция: Micro-frontends должны быть изолированы друг от друга, чтобы предотвратить каскадные сбои и обеспечить стабильность.

Зачем использовать Micro-Frontends?

Принятие архитектуры micro-frontend предлагает несколько существенных преимуществ, особенно для больших и сложных приложений:

• Улучшенная масштабируемость: Разделение frontend на более мелкие единицы упрощает масштабирование приложения по мере необходимости.
• Более быстрые циклы разработки: Независимые команды могут работать параллельно, что приводит к ускорению разработки и выпуску циклов.
• Повышенная автономия команды: Команды имеют больше контроля над своим кодом и могут принимать решения независимо.
• Более простое обслуживание: Меньшие кодовые базы легче поддерживать и отлаживать.
• Технологическая независимость: Команды могут выбирать лучшие технологии для своих конкретных нужд, что позволяет внедрять инновации и экспериментировать.
• Сниженный риск: Развертывания становятся меньше и чаще, что снижает риск крупномасштабных сбоев.

Введение в Module Federation

Module Federation — это функция, представленная в Webpack 5, которая позволяет JavaScript-приложениям динамически загружать код из других приложений во время выполнения. Это позволяет создавать по-настоящему независимые и компонуемые micro-frontends. Вместо того, чтобы собирать все в один пакет, Module Federation позволяет различным приложениям обмениваться модулями друг с другом и использовать их, как если бы они были локальными зависимостями.

В отличие от традиционных подходов к micro-frontends, которые полагаются на iframes или веб-компоненты, Module Federation обеспечивает более плавное и интегрированное взаимодействие с пользователем. Он позволяет избежать накладных расходов на производительность и сложности, связанных с этими другими методами.

Как работает Module Federation

Module Federation работает по принципу «предоставления» и «потребления» модулей. Одно приложение ( «хост» или «контейнер») может предоставлять модули, а другие приложения ( «удаленные») могут использовать эти предоставленные модули. Вот разбивка процесса:

1. Предоставление модулей: Micro-frontend, настроенный как «удаленное» приложение в Webpack, предоставляет определенные модули (компоненты, функции, утилиты) через файл конфигурации. Эта конфигурация определяет модули, которыми нужно поделиться, и соответствующие точки входа.
2. Потребление модулей: Другой micro-frontend, настроенный как «хост» или «контейнерное» приложение, объявляет удаленное приложение как зависимость. Он указывает URL-адрес, по которому можно найти манифест федерации модулей удаленного приложения (небольшой JSON-файл, описывающий предоставленные модули).
3. Разрешение во время выполнения: Когда хост-приложению необходимо использовать модуль из удаленного приложения, оно динамически извлекает манифест федерации модулей удаленного приложения. Затем Webpack разрешает зависимость модуля и загружает необходимый код из удаленного приложения во время выполнения.
4. Совместное использование кода: Module Federation также позволяет совместно использовать код между хостом и удаленными приложениями. Если оба приложения используют одну и ту же версию общей зависимости (например, React, lodash), код будет совместно использоваться, избегая дублирования и уменьшая размеры пакетов.

Настройка Module Federation: практический пример

Давайте проиллюстрируем Module Federation на простом примере, включающем два micro-frontends: «Каталог товаров» и «Корзина». Каталог товаров предоставит компонент списка продуктов, который корзина будет использовать для отображения связанных продуктов.

Структура проекта

  
  micro-frontend-example/
    product-catalog/
      src/
        components/
          ProductList.jsx
        index.js
        webpack.config.js
    shopping-cart/
      src/
        components/
          RelatedProducts.jsx
        index.js
        webpack.config.js
  

Каталог товаров (удаленный)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'product_catalog',
        filename: 'remoteEntry.js',
        exposes: {
          './ProductList': './src/components/ProductList',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Пояснение:

• name: Уникальное имя удаленного приложения.
• filename: Имя файла точки входа, который будет предоставлен. Этот файл содержит манифест федерации модулей.
• exposes: Определяет, какие модули будут предоставлены этим приложением. В данном случае мы предоставляем компонент `ProductList` из `src/components/ProductList.jsx` под именем `./ProductList`.
• shared: Указывает зависимости, которыми следует поделиться между хостом и удаленными приложениями. Это имеет решающее значение для избежания дублирования кода и обеспечения совместимости. `singleton: true` гарантирует, что будет загружен только один экземпляр общей зависимости. `eager: true` загружает общую зависимость изначально, что может повысить производительность. `requiredVersion` определяет приемлемый диапазон версий для общей зависимости.

src/components/ProductList.jsx

  
  import React from 'react';

  const ProductList = ({ products }) => (
    

      {products.map((product) => (
        
{product.name} - ${product.price}
      ))}
    
  );

  export default ProductList;
  

Корзина (хост)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'shopping_cart',
        remotes: {
          product_catalog: 'product_catalog@http://localhost:3001/remoteEntry.js',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Пояснение:

• name: Уникальное имя хост-приложения.
• remotes: Определяет удаленные приложения, из которых это приложение будет использовать модули. В данном случае мы объявляем удаленный элемент с именем `product_catalog` и указываем URL-адрес, по которому можно найти его файл `remoteEntry.js`. Формат: `remoteName: 'remoteName@remoteEntryUrl'`.
• shared: Как и удаленное приложение, хост-приложение также определяет свои общие зависимости. Это гарантирует, что хост- и удаленные приложения используют совместимые версии общих библиотек.

src/components/RelatedProducts.jsx

  
  import React, { useEffect, useState } from 'react';
  import ProductList from 'product_catalog/ProductList';

  const RelatedProducts = () => {
    const [products, setProducts] = useState([]);

    useEffect(() => {
      // Fetch related products data (e.g., from an API)
      const fetchProducts = async () => {
        // Replace with your actual API endpoint
        const response = await fetch('https://fakestoreapi.com/products?limit=3');
        const data = await response.json();
        setProducts(data);
      };

      fetchProducts();
    }, []);

    return (
      

        
Похожие товары
        {products.length > 0 ?  : 
Загрузка...
}
      
    );
  };

  export default RelatedProducts;
  

Пояснение:

• import ProductList from 'product_catalog/ProductList'; Эта строка импортирует компонент `ProductList` из удаленного `product_catalog`. Синтаксис `remoteName/moduleName` предписывает Webpack получить модуль из указанного удаленного приложения.
• Затем компонент использует импортированный компонент `ProductList` для отображения связанных продуктов.

Запуск примера

1. Запустите приложения «Каталог товаров» и «Корзина», используя соответствующие серверы разработки (например, `npm start`). Убедитесь, что они работают на разных портах (например, Каталог товаров на порту 3001, а Корзина на порту 3000).
2. Перейдите к приложению «Корзина» в своем браузере.
3. Вы должны увидеть раздел «Похожие товары», который отображается компонентом `ProductList` из приложения «Каталог товаров».

Расширенные концепции Module Federation

Помимо базовой настройки, Module Federation предлагает несколько расширенных функций, которые могут улучшить вашу архитектуру micro-frontend:

Совместное использование кода и версионирование

Как показано в примере, Module Federation позволяет совместно использовать код между хостом и удаленными приложениями. Это достигается с помощью опции `shared` в Webpack. Указав общие зависимости, вы можете избежать дублирования кода и уменьшить размеры пакетов. Правильное версионирование общих зависимостей имеет решающее значение для обеспечения совместимости и предотвращения конфликтов. Semantic versioning (SemVer) — широко используемый стандарт для версионирования программного обеспечения, позволяющий определять совместимые диапазоны версий (например, `^17.0.0` допускает любую версию, большую или равную 17.0.0, но меньшую 18.0.0).

Динамические удаленные объекты

В предыдущем примере удаленный URL-адрес был жестко закодирован в файле `webpack.config.js`. Однако во многих реальных сценариях может потребоваться динамически определять удаленный URL-адрес во время выполнения. Этого можно добиться с помощью удаленной конфигурации на основе promise:

  
  // webpack.config.js
  remotes: {
    product_catalog: new Promise(resolve => {
      // Fetch the remote URL from a configuration file or API
      fetch('/config.json')
        .then(response => response.json())
        .then(config => {
          const remoteUrl = config.productCatalogUrl;
          resolve(`product_catalog@${remoteUrl}/remoteEntry.js`);
        });
    }),
  },
  

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

Асинхронная загрузка модулей

Module Federation поддерживает асинхронную загрузку модулей, позволяя загружать модули по запросу. Это может улучшить время первоначальной загрузки вашего приложения, откладывая загрузку некритических модулей.

  
  // RelatedProducts.jsx
  import React, { Suspense, lazy } from 'react';

  const ProductList = lazy(() => import('product_catalog/ProductList'));

  const RelatedProducts = () => {
    return (
      

        
Похожие товары
        Загрузка...
}>
          
        
      
    );
  };
  

Используя `React.lazy` и `Suspense`, вы можете асинхронно загружать компонент `ProductList` из удаленного приложения. Компонент `Suspense` предоставляет резервный пользовательский интерфейс (например, индикатор загрузки) во время загрузки модуля.

Федеративные стили и ресурсы

Module Federation также можно использовать для совместного использования стилей и ресурсов между micro-frontends. Это может помочь поддерживать согласованный внешний вид вашего приложения.

Чтобы совместно использовать стили, вы можете предоставить CSS-модули или стилизованные компоненты из удаленного приложения. Чтобы совместно использовать ресурсы (например, изображения, шрифты), вы можете настроить Webpack для копирования ресурсов в общее местоположение, а затем ссылаться на них из хост-приложения.

Лучшие практики для Module Federation

При реализации Module Federation важно следовать лучшим практикам, чтобы обеспечить успешную и удобную для обслуживания архитектуру:

• Определите четкие границы: Четко определите границы между micro-frontends, чтобы избежать жесткой связи и обеспечить независимую развертываемость.
• Установите протоколы связи: Определите четкие протоколы связи между micro-frontends. Рассмотрите возможность использования шин событий, библиотек управления общим состоянием или пользовательских API.
• Управляйте общими зависимостями осторожно: Тщательно управляйте общими зависимостями, чтобы избежать конфликтов версий и обеспечить совместимость. Используйте семантическое управление версиями и рассмотрите возможность использования инструмента управления зависимостями, такого как npm или yarn.
• Реализуйте надежную обработку ошибок: Реализуйте надежную обработку ошибок, чтобы предотвратить каскадные сбои и обеспечить стабильность вашего приложения.
• Контролируйте производительность: Контролируйте производительность ваших micro-frontends, чтобы выявить узкие места и оптимизировать производительность.
• Автоматизируйте развертывания: Автоматизируйте процесс развертывания, чтобы обеспечить последовательные и надежные развертывания.
• Используйте последовательный стиль кодирования: Обеспечьте последовательный стиль кодирования во всех micro-frontends, чтобы улучшить читаемость и удобство обслуживания. Такие инструменты, как ESLint и Prettier, могут помочь в этом.
• Документируйте свою архитектуру: Документируйте архитектуру micro-frontend, чтобы все члены команды понимали систему и как она работает.

Module Federation против других подходов к micro-frontend

Хотя Module Federation является мощной техникой для реализации micro-frontends, это не единственный подход. Другие популярные методы включают:

• Iframes: Iframes обеспечивают сильную изоляцию между micro-frontends, но их может быть трудно интегрировать беспрепятственно, и они могут иметь накладные расходы на производительность.
• Веб-компоненты: Веб-компоненты позволяют создавать многоразовые элементы пользовательского интерфейса, которые можно использовать в разных micro-frontends. Однако их реализация может быть сложнее, чем Module Federation.
• Интеграция во время сборки: Этот подход предполагает сборку всех micro-frontends в одно приложение во время сборки. Хотя это может упростить развертывание, оно снижает автономию команды и увеличивает риск конфликтов.
• Single-SPA: Single-SPA — это фреймворк, который позволяет объединять несколько одностраничных приложений в одно приложение. Он обеспечивает более гибкий подход, чем интеграция во время сборки, но его настройка может быть более сложной.

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

Реальные примеры Module Federation

Хотя конкретные реализации компаний часто являются конфиденциальными, общие принципы Module Federation применяются в различных отраслях и сценариях. Вот несколько потенциальных примеров:

• Платформы электронной коммерции: Платформа электронной коммерции может использовать Module Federation для разделения различных разделов веб-сайта, таких как каталог продуктов, корзина, процесс оформления заказа и управление учетной записью пользователя, на отдельные micro-frontends. Это позволяет разным командам работать над этими разделами независимо и развертывать обновления, не затрагивая остальную часть платформы. Например, команда в *Германии* может сосредоточиться на каталоге товаров, а команда в *Индии* управляет корзиной.
• Приложения финансовых услуг: Приложение финансовых услуг может использовать Module Federation для изоляции конфиденциальных функций, таких как торговые платформы и управление учетными записями, в отдельные micro-frontends. Это повышает безопасность и позволяет проводить независимый аудит этих критических компонентов. Представьте себе команду в *Лондоне*, специализирующуюся на функциях торговой платформы, и другую команду в *Нью-Йорке*, занимающуюся управлением учетными записями.
• Системы управления контентом (CMS): CMS может использовать Module Federation, чтобы позволить разработчикам создавать и развертывать пользовательские модули в качестве micro-frontends. Это обеспечивает большую гибкость и настройку для пользователей CMS. Команда в *Японии* может создать специализированный модуль галереи изображений, а команда в *Бразилии* — расширенный текстовый редактор.
• Приложения для здравоохранения: Приложение для здравоохранения может использовать Module Federation для интеграции различных систем, таких как электронные медицинские карты (EHR), порталы для пациентов и системы выставления счетов, в качестве отдельных micro-frontends. Это улучшает совместимость и упрощает интеграцию новых систем. Например, команда в *Канаде* может интегрировать новый модуль телемедицины, а команда в *Австралии* сосредоточится на улучшении работы с порталом для пациентов.

Заключение

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

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