Овладяване на JavaScript Module Federation: Силата на споделения обхват и споделянето на зависимости

В бързо развиващия се свят на уеб разработката, изграждането на мащабируеми и лесни за поддръжка приложения често включва възприемането на сложни архитектурни модели. Сред тях концепцията за микрофронтенди придоби значителна популярност, позволявайки на екипите да разработват и внедряват части от приложението независимо. В основата на безпроблемната интеграция и ефективното споделяне на код между тези независими единици стои плъгинът Module Federation на Webpack, а критичен компонент от неговата мощ е споделеният обхват (shared scope).

Това изчерпателно ръководство се задълбочава в механизма на споделения обхват в JavaScript Module Federation. Ще разгледаме какво представлява, защо е от съществено значение за споделянето на зависимости, как работи и практически стратегии за ефективното му внедряване. Нашата цел е да предоставим на разработчиците знанията, необходими за използването на тази мощна функция за подобрена производителност, намалени размери на пакетите (bundles) и по-добро изживяване за разработчиците в разнообразни глобални екипи.

Какво е JavaScript Module Federation?

Преди да се потопим в споделения обхват, е изключително важно да разберем основната концепция на Module Federation. Представен с Webpack 5, Module Federation е решение както по време на компилация (build-time), така и по време на изпълнение (run-time), което позволява на JavaScript приложенията динамично да споделят код (като библиотеки, рамки или дори цели компоненти) между отделно компилирани приложения. Това означава, че можете да имате няколко различни приложения (често наричани „отдалечени“ или „потребители“), които могат да зареждат код от „контейнерно“ или „хост“ приложение и обратно.

Основните предимства на Module Federation включват:

• Споделяне на код: Елиминира излишния код в множество приложения, намалявайки общия размер на пакетите и подобрявайки времето за зареждане.
• Независимо внедряване: Екипите могат да разработват и внедряват различни части на голямо приложение независимо, насърчавайки гъвкавост и по-бързи цикли на издаване.
• Технологична независимост: Въпреки че се използва предимно с Webpack, до известна степен улеснява споделянето между различни инструменти за компилация или рамки, насърчавайки гъвкавостта.
• Интеграция по време на изпълнение: Приложенията могат да се композират по време на изпълнение, което позволява динамични актуализации и гъвкави структури на приложенията.

Проблемът: Излишни зависимости в микрофронтендите

Представете си сценарий, в който имате няколко микрофронтенда, които зависят от една и съща версия на популярна UI библиотека като React или библиотека за управление на състоянието като Redux. Без механизъм за споделяне, всеки микрофронтенд би пакетирал собствено копие на тези зависимости. Това води до:

• Раздути размери на пакетите: Всяко приложение ненужно дублира общи библиотеки, което води до по-големи размери за изтегляне от потребителите.
• Повишена консумация на памет: Множество инстанции на една и съща библиотека, заредени в браузъра, могат да консумират повече памет.
• Непоследователно поведение: Различни версии на споделени библиотеки в различните приложения могат да доведат до скрити бъгове и проблеми със съвместимостта.
• Изгубени мрежови ресурси: Потребителите може да изтеглят една и съща библиотека няколко пъти, ако навигират между различни микрофронтенди.

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

Разбиране на споделения обхват в Module Federation

Споделеният обхват (shared scope), често конфигуриран чрез опцията shared в плъгина Module Federation, е механизмът, който позволява на множество независимо внедрени приложения да споделят зависимости. Когато е конфигуриран, Module Federation гарантира, че една-единствена инстанция на определена зависимост се зарежда и става достъпна за всички приложения, които я изискват.

В основата си споделеният обхват работи, като създава глобален регистър или контейнер за споделени модули. Когато едно приложение поиска споделена зависимост, Module Federation проверява този регистър. Ако зависимостта вече присъства (т.е. заредена е от друго приложение или от хоста), се използва съществуващата инстанция. В противен случай, той зарежда зависимостта и я регистрира в споделения обхват за бъдеща употреба.

Конфигурацията обикновено изглежда така:

            // webpack.config.js

const { ModuleFederationPlugin } = require('webpack');

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

            

              
                Copy
              
            
          

Ключови опции за конфигурация на споделени зависимости:

• singleton: true: Това е може би най-критичната опция. Когато е зададена на true, тя гарантира, че само една-единствена инстанция на споделената зависимост се зарежда във всички консумиращи приложения. Ако няколко приложения се опитат да заредят една и съща singleton зависимост, Module Federation ще им предостави същата инстанция.
• eager: true: По подразбиране споделените зависимости се зареждат „мързеливо“ (lazily), което означава, че се извличат само когато са изрично импортирани или използвани. Задаването на eager: true принуждава зависимостта да бъде заредена веднага щом приложението стартира, дори и да не се използва веднага. Това може да бъде полезно за критични библиотеки като рамки, за да се гарантира, че са налични от самото начало.
• requiredVersion: '...': Тази опция указва необходимата версия на споделената зависимост. Module Federation ще се опита да намери съответствие с исканата версия. Ако няколко приложения изискват различни версии, Module Federation има механизми за справяне с това (обсъдено по-късно).
• version: '...': Можете изрично да зададете версията на зависимостта, която ще бъде публикувана в споделения обхват.
• import: false: Тази настройка казва на Module Federation да не пакетира автоматично споделената зависимост. Вместо това, той очаква тя да бъде предоставена външно (което е поведението по подразбиране при споделяне).
• packageDir: '...': Указва директорията на пакета, от която да се зареди споделената зависимост, полезно при monorepos.

Как споделеният обхват позволява споделяне на зависимости

Нека разгледаме процеса с практически пример. Представете си, че имаме основно „контейнерно“ приложение и две „отдалечени“ приложения, `app1` и `app2`. И трите приложения зависят от `react` и `react-dom` версия 18.

Сценарий 1: Контейнерното приложение споделя зависимости

В тази често срещана конфигурация контейнерното приложение дефинира споделените зависимости. Файлът `remoteEntry.js`, генериран от Module Federation, експонира тези споделени модули.

Webpack конфигурация на контейнера (`container/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      filename: 'remoteEntry.js',
      exposes: {
        './App': './src/App',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Сега `app1` и `app2` ще консумират тези споделени зависимости.

Webpack конфигурация на `app1` (`app1/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      filename: 'remoteEntry.js',
      exposes: {
        './Feature1': './src/Feature1',
      },
      remotes: {
        'container': 'container@http://localhost:3000/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Webpack конфигурация на `app2` (`app2/webpack.config.js`):

Конфигурацията за `app2` би била подобна на тази за `app1`, като също декларира `react` и `react-dom` като споделени със същите изисквания за версия.

Как работи по време на изпълнение:

1. Контейнерното приложение се зарежда първо, правейки своите споделени инстанции на `react` и `react-dom` достъпни в своя Module Federation обхват.
2. Когато `app1` се зареди, то изисква `react` и `react-dom`. Module Federation в `app1` вижда, че те са маркирани като споделени и `singleton: true`. Той проверява глобалния обхват за съществуващи инстанции. Ако контейнерът вече ги е заредил, `app1` преизползва тези инстанции.
3. По подобен начин, когато `app2` се зареди, то също преизползва същите инстанции на `react` и `react-dom`.

Това води до зареждането само на едно копие на `react` и `react-dom` в браузъра, което значително намалява общия размер за изтегляне.

Сценарий 2: Споделяне на зависимости между отдалечени приложения

Module Federation също така позволява на отдалечените приложения да споделят зависимости помежду си. Ако `app1` и `app2` използват библиотека, която *не* се споделя от контейнера, те все пак могат да я споделят, ако и двете я декларират като споделена в съответните си конфигурации.

Пример: Да кажем, че `app1` и `app2` използват помощната библиотека `lodash`.

Webpack конфигурация на `app1` (добавяне на lodash):

            
// ... within ModuleFederationPlugin for app1
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

Webpack конфигурация на `app2` (добавяне на lodash):

            
// ... within ModuleFederationPlugin for app2
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

В този случай, дори ако контейнерът не споделя изрично `lodash`, `app1` и `app2` ще успеят да споделят една-единствена инстанция на `lodash` помежду си, при условие че са заредени в един и същ контекст на браузъра.

Справяне с несъответствия във версиите

Едно от най-често срещаните предизвикателства при споделянето на зависимости е съвместимостта на версиите. Какво се случва, когато `app1` изисква `react` v18.1.0, а `app2` изисква `react` v18.2.0? Module Federation предоставя надеждни стратегии за управление на тези сценарии.

1. Стриктно съвпадение на версиите (поведение по подразбиране за `requiredVersion`)

Когато посочите точна версия (напр. '18.1.0') или строг диапазон (напр. '^18.1.0'), Module Federation ще наложи това. Ако едно приложение се опита да зареди споделена зависимост с версия, която не удовлетворява изискването на друго приложение, което вече я използва, това може да доведе до грешки.

2. Диапазони на версиите и резервни варианти (Fallbacks)

Опцията requiredVersion поддържа диапазони на семантично версиониране (SemVer). Например, '^18.0.0' означава всяка версия от 18.0.0 до (но без да включва) 19.0.0. Ако няколко приложения изискват версии в този диапазон, Module Federation обикновено ще използва най-високата съвместима версия, която удовлетворява всички изисквания.

Разгледайте следния пример:

• Контейнер: shared: { 'react': { requiredVersion: '^18.0.0' } }
• `app1`: shared: { 'react': { requiredVersion: '^18.1.0' } }
• `app2`: shared: { 'react': { requiredVersion: '^18.2.0' } }

Ако контейнерът се зареди първи, той установява `react` v18.0.0 (или каквато версия всъщност пакетира). Когато `app1` поиска `react` с `^18.1.0`, може да се провали, ако версията на контейнера е по-ниска от 18.1.0. Въпреки това, ако `app1` се зареди първи и предостави `react` v18.1.0, а след това `app2` поиска `react` с `^18.2.0`, Module Federation ще се опита да удовлетвори изискването на `app2`. Ако инстанцията на `react` v18.1.0 вече е заредена, може да възникне грешка, тъй като v18.1.0 не удовлетворява `^18.2.0`.

За да се смекчи този проблем, най-добрата практика е да се дефинират споделени зависимости с най-широкия приемлив диапазон на версиите, обикновено в контейнерното приложение. Например, използването на '^18.0.0' позволява гъвкавост. Ако конкретно отдалечено приложение има твърда зависимост от по-нова пач версия, то трябва да бъде конфигурирано да предоставя изрично тази версия.

3. Използване на `shareKey` и `shareScope`

Module Federation също така ви позволява да контролирате ключа, под който се споделя модул, и обхвата, в който той се намира. Това може да бъде полезно за напреднали сценарии, като например споделяне на различни версии на една и съща библиотека под различни ключове.

4. Опцията `strictVersion`

Когато strictVersion е активирана (което е по подразбиране за requiredVersion), Module Federation изхвърля грешка, ако дадена зависимост не може да бъде удовлетворена. Задаването на strictVersion: false може да позволи по-гъвкаво управление на версиите, като Module Federation може да се опита да използва по-стара версия, ако по-нова не е налична, но това може да доведе до грешки по време на изпълнение.

Най-добри практики за използване на споделен обхват

За да използвате ефективно споделения обхват на Module Federation и да избегнете често срещани капани, обмислете тези най-добри практики:

1. Централизирайте споделените зависимости: Определете основно приложение (често контейнерът или специално приложение за споделени библиотеки) да бъде източник на истина за общи, стабилни зависимости като рамки (React, Vue, Angular), библиотеки с UI компоненти и библиотеки за управление на състоянието.
2. Дефинирайте широки диапазони на версиите: Използвайте SemVer диапазони (напр. '^18.0.0') за споделени зависимости в основното споделящо приложение. Това позволява на други приложения да използват съвместими версии, без да налага строги актуализации в цялата екосистема.
3. Документирайте ясно споделените зависимости: Поддържайте ясна документация за това кои зависимости се споделят, техните версии и кои приложения са отговорни за споделянето им. Това помага на екипите да разберат графа на зависимостите.
4. Следете размерите на пакетите: Редовно анализирайте размерите на пакетите на вашите приложения. Споделеният обхват на Module Federation трябва да доведе до намаляване на размера на динамично заредените части (chunks), тъй като общите зависимости са външни.
5. Управлявайте недетерминистични зависимости: Бъдете предпазливи със зависимости, които се актуализират често или имат нестабилни API-та. Споделянето на такива зависимости може да изисква по-внимателно управление на версиите и тестване.
6. Използвайте `eager: true` разумно: Въпреки че `eager: true` гарантира ранно зареждане на зависимост, прекомерната му употреба може да доведе до по-голямо първоначално зареждане. Използвайте го за критични библиотеки, които са от съществено значение за стартирането на приложението.
7. Тестването е от решаващо значение: Тествайте щателно интеграцията на вашите микрофронтенди. Уверете се, че споделените зависимости се зареждат правилно и че конфликтите във версиите се обработват гладко. Автоматизираното тестване, включително интеграционни и end-to-end тестове, е жизненоважно.
8. Обмислете Monorepos за простота: За екипи, които започват с Module Federation, управлението на споделени зависимости в monorepo (използвайки инструменти като Lerna или Yarn Workspaces) може да опрости настройката и да осигури последователност. Опцията `packageDir` е особено полезна тук.
9. Справяйте се с крайни случаи с `shareKey` и `shareScope`: Ако срещнете сложни сценарии за версиониране или трябва да експонирате различни версии на една и съща библиотека, проучете опциите `shareKey` и `shareScope` за по-детайлен контрол.
10. Съображения за сигурност: Уверете се, че споделените зависимости се извличат от надеждни източници. Внедрете най-добрите практики за сигурност във вашия процес на компилация и внедряване.

Глобално въздействие и съображения

За глобалните екипи за разработка Module Federation и неговият споделен обхват предлагат значителни предимства:

• Последователност в различните региони: Гарантира, че всички потребители, независимо от географското им местоположение, изживяват приложението с едни и същи основни зависимости, намалявайки регионалните несъответствия.
• По-бързи итерационни цикли: Екипи в различни часови зони могат да работят по независими функции или микрофронтенди, без постоянно да се притесняват за дублиране на общи библиотеки или да си пречат взаимно по отношение на версиите на зависимостите.
• Оптимизирано за разнообразни мрежи: Намаляването на общия размер за изтегляне чрез споделени зависимости е особено полезно за потребители с по-бавни или лимитирани интернет връзки, които са често срещани в много части на света.
• Опростено въвеждане: Новите разработчици, които се присъединяват към голям проект, могат по-лесно да разберат архитектурата на приложението и управлението на зависимостите, когато общите библиотеки са ясно дефинирани и споделени.

Въпреки това, глобалните екипи трябва да имат предвид и:

• CDN стратегии: Ако споделените зависимости се хостват на CDN, уверете се, че CDN има добро глобално покритие и ниска латентност за всички целеви региони.
• Офлайн поддръжка: За приложения, изискващи офлайн възможности, управлението на споделени зависимости и тяхното кеширане става по-сложно.
• Съответствие с регулациите: Уверете се, че споделянето на библиотеки е в съответствие с всички приложими лицензи за софтуер или разпоредби за поверителност на данните в различните юрисдикции.

Често срещани капани и как да ги избегнем

1. Неправилно конфигуриран `singleton`

Проблем: Пропускане на задаването на singleton: true за библиотеки, които трябва да имат само една инстанция.

Решение: Винаги задавайте singleton: true за рамки, библиотеки и помощни програми, които възнамерявате да споделяте уникално във вашите приложения.

2. Непоследователни изисквания за версии

Проблем: Различни приложения, указващи коренно различни, несъвместими диапазони на версии за една и съща споделена зависимост.

Решение: Стандартизирайте изискванията за версиите, особено в контейнерното приложение. Използвайте широки SemVer диапазони и документирайте всички изключения.

3. Прекомерно споделяне на несъществени библиотеки

Проблем: Опит за споделяне на всяка малка помощна библиотека, което води до сложна конфигурация и потенциални конфликти.

Решение: Фокусирайте се върху споделянето на големи, общи и стабилни зависимости. Малки, рядко използвани помощни програми е по-добре да бъдат пакетирани локално, за да се избегне сложност.

4. Неправилна обработка на файла `remoteEntry.js`

Проблем: Файлът `remoteEntry.js` не е достъпен или не се сервира правилно на консумиращите приложения.

Решение: Уверете се, че вашата стратегия за хостинг на отдалечените входове (remote entries) е надеждна и че URL адресите, посочени в конфигурацията `remotes`, са точни и достъпни.

5. Игнориране на последиците от `eager: true`

Проблем: Задаване на eager: true на твърде много зависимости, което води до бавно първоначално време за зареждане.

Решение: Използвайте eager: true само за зависимости, които са абсолютно критични за първоначалното изобразяване или основната функционалност на вашите приложения.

Заключение

Споделеният обхват на JavaScript Module Federation е мощен инструмент за изграждане на модерни, мащабируеми уеб приложения, особено в рамките на микрофронтенд архитектура. Като позволява ефективно споделяне на зависимости, той се справя с проблеми като дублиране на код, раздуване и непоследователност, което води до подобрена производителност и поддръжка. Разбирането и правилната конфигурация на опцията shared, особено свойствата singleton и requiredVersion, е ключът към отключването на тези предимства.

Тъй като глобалните екипи за разработка все повече възприемат стратегии за микрофронтенди, овладяването на споделения обхват на Module Federation става от първостепенно значение. Като се придържате към най-добрите практики, внимателно управлявате версионирането и провеждате щателно тестване, можете да използвате тази технология за изграждане на стабилни, високопроизводителни и лесни за поддръжка приложения, които ефективно обслужват разнообразна международна потребителска база.

Прегърнете силата на споделения обхват и проправете пътя към по-ефективна и съвместна уеб разработка във вашата организация.