JavaScript Module Federation: Frigjør kraften i kjøretidsdeling for globale applikasjoner

I dagens raskt utviklende digitale landskap er det avgjørende å bygge skalerbare, vedlikeholdbare og samarbeidsorienterte webapplikasjoner. Etter hvert som utviklingsteam vokser og applikasjoner blir mer komplekse, blir behovet for effektiv kodedeling og avkobling stadig viktigere. JavaScript Module Federation, en banebrytende funksjon introdusert med Webpack 5, tilbyr en kraftig løsning ved å muliggjøre deling av kode i kjøretid mellom uavhengig distribuerte applikasjoner. Dette blogginnlegget dykker ned i kjernekonseptene i Module Federation, med fokus på dens evner til kjøretidsdeling, og utforsker hvordan det kan revolusjonere måten globale team bygger og administrerer sine webapplikasjoner på.

Det utviklende landskapet for webutvikling og behovet for deling

Historisk sett innebar webutvikling ofte monolittiske applikasjoner der all kode befant seg i én enkelt kodebase. Selv om denne tilnærmingen kan være egnet for mindre prosjekter, blir den raskt uhåndterlig etter hvert som applikasjonene skalerer. Avhengigheter blir sammenfiltrede, byggetidene øker, og distribusjon av oppdateringer kan være en kompleks og risikabel affære. Fremveksten av mikrotjenester i backend-utvikling banet vei for lignende arkitektoniske mønstre på frontend, noe som førte til fremveksten av mikrofrontends.

Mikrofrontends har som mål å bryte ned store, komplekse frontend-applikasjoner i mindre, uavhengige og distribuerbare enheter. Dette lar forskjellige team jobbe autonomt med ulike deler av applikasjonen, noe som fører til raskere utviklingssykluser og forbedret teamautonomi. En betydelig utfordring i mikrofrontend-arkitekturer har imidlertid alltid vært effektiv kodedeling. Duplisering av felles biblioteker, UI-komponenter eller hjelpefunksjoner på tvers av flere mikrofrontends fører til:

• Økte pakkestørrelser: Hver applikasjon bærer sin egen kopi av delte avhengigheter, noe som blåser opp den totale nedlastingsstørrelsen for brukerne.
• Inkonsistente avhengigheter: Ulike mikrofrontends kan ende opp med å bruke forskjellige versjoner av det samme biblioteket, noe som fører til kompatibilitetsproblemer og uforutsigbar oppførsel.
• Vedlikeholdsbyrde: Oppdatering av delt kode krever endringer på tvers av flere applikasjoner, noe som øker risikoen for feil og bremser distribusjonen.
• Bortkastede ressurser: Å laste ned den samme koden flere ganger er ineffektivt for både klienten og serveren.

Module Federation adresserer disse utfordringene direkte ved å introdusere en mekanisme for ekte kodedeling i kjøretid.

Hva er JavaScript Module Federation?

JavaScript Module Federation, primært implementert gjennom Webpack 5, er en funksjon i byggeverktøy som lar JavaScript-applikasjoner dynamisk laste kode fra andre applikasjoner i kjøretid. Det muliggjør opprettelsen av flere uavhengige applikasjoner som kan dele kode og avhengigheter uten å kreve et monorepo eller en kompleks byggetidsintegrasjonsprosess.

Kjerneideen er å definere "remotes" (applikasjoner som eksponerer moduler) og "hosts" (applikasjoner som konsumerer moduler fra remotes). Disse remotes og hosts kan distribueres uavhengig, noe som gir betydelig fleksibilitet i håndteringen av komplekse applikasjoner og muliggjør ulike arkitektoniske mønstre.

Forstå kjøretidsdeling: kjernen i Module Federation

Kjøretidsdeling er hjørnesteinen i kraften til Module Federation. I motsetning til tradisjonelle teknikker for kodesplitting eller håndtering av delte avhengigheter som ofte skjer på byggetidspunktet, lar Module Federation applikasjoner oppdage og laste moduler fra andre applikasjoner direkte i brukerens nettleser. Dette betyr at et felles bibliotek, et delt UI-komponentbibliotek, eller til og med en funksjonsmodul kan lastes én gang av én applikasjon og deretter gjøres tilgjengelig for andre applikasjoner som trenger det.

La oss bryte ned hvordan dette fungerer:

Nøkkelkonsepter:

• Exposes (Eksponerer): En applikasjon kan 'eksponere' visse moduler (f.eks. en React-komponent, en hjelpefunksjon) som andre applikasjoner kan konsumere. Disse eksponerte modulene pakkes inn i en container som kan lastes eksternt.
• Remotes: En applikasjon som eksponerer moduler regnes som en 'remote'. Den eksponerer sine moduler via en delt konfigurasjon.
• Consumes (Konsumerer): En applikasjon som trenger å bruke moduler fra en remote er en 'konsument' eller 'host'. Den konfigurerer seg selv til å vite hvor den skal finne remote-applikasjonene og hvilke moduler den skal laste.
• Shared Modules (Delte moduler): Module Federation lar deg definere delte moduler. Når flere applikasjoner konsumerer den samme delte modulen, lastes kun én instans av den modulen og deles mellom dem. Dette er et kritisk aspekt for å optimalisere pakkestørrelser og forhindre avhengighetskonflikter.

Mekanismen:

Når en host-applikasjon trenger en modul fra en remote, ber den om den fra remote-applikasjonens container. Remote-containeren laster deretter dynamisk den forespurte modulen. Hvis modulen allerede er lastet av en annen konsumerende applikasjon, vil den bli delt. Denne dynamiske lasting og deling skjer sømløst i kjøretid, og gir en svært effektiv måte å håndtere avhengigheter på.

Fordeler med Module Federation for global utvikling

Fordelene med å ta i bruk Module Federation for å bygge globale applikasjoner er betydelige og vidtrekkende:

1. Forbedret skalerbarhet og vedlikeholdbarhet:

Ved å bryte ned en stor applikasjon i mindre, uavhengige mikrofrontends, fremmer Module Federation i seg selv skalerbarhet. Team kan jobbe med individuelle mikrofrontends uten å påvirke andre, noe som tillater parallell utvikling og uavhengige distribusjoner. Dette reduserer den kognitive belastningen forbundet med å administrere en massiv kodebase og gjør applikasjonen mer vedlikeholdbar over tid.

2. Optimaliserte pakkestørrelser og ytelse:

Den mest betydningsfulle fordelen med kjøretidsdeling er reduksjonen i total nedlastingsstørrelse. I stedet for at hver applikasjon dupliserer felles biblioteker (som React, Lodash, eller et tilpasset UI-komponentbibliotek), lastes disse avhengighetene én gang og deles. Dette fører til:

• Raskere innledende lastetider: Brukere laster ned mindre kode, noe som resulterer i en raskere innledende gjengivelse av applikasjonen.
• Forbedret påfølgende navigasjon: Når man navigerer mellom mikrofrontends som deler avhengigheter, gjenbrukes de allerede lastede modulene, noe som fører til en smidigere brukeropplevelse.
• Redusert serverbelastning: Mindre data overføres fra serveren, noe som potensielt kan senke hostingkostnadene.

Tenk deg en global e-handelsplattform med distinkte seksjoner for produktoppføringer, brukerkontoer og kasse. Hvis hver seksjon er en egen mikrofrontend, men alle er avhengige av et felles UI-komponentbibliotek for knapper, skjemaer og navigasjon, sikrer Module Federation at dette biblioteket bare lastes én gang, uavhengig av hvilken seksjon brukeren besøker først.

3. Økt teamautonomi og samarbeid:

Module Federation gir ulike team, potensielt lokalisert i forskjellige globale regioner, muligheten til å jobbe uavhengig med sine respektive mikrofrontends. De kan velge sine egne teknologistakker (innenfor rimelighetens grenser, for å opprettholde et visst nivå av konsistens) og distribusjonsplaner. Denne autonomien fremmer raskere innovasjon og reduserer kommunikasjonsbyrden. Samtidig oppmuntrer evnen til å dele felles kode til samarbeid, ettersom team kan bidra til og dra nytte av delte biblioteker og komponenter.

Se for deg en global finansinstitusjon med separate team i Europa, Asia og Nord-Amerika som er ansvarlige for ulike produkttilbud. Module Federation lar hvert team utvikle sine spesifikke funksjoner samtidig som de utnytter en felles autentiseringstjeneste eller et delt grafbibliotek utviklet av et sentralt team. Dette fremmer gjenbruk og sikrer konsistens på tvers av ulike produktlinjer.

4. Teknologiagnostisisme (med forbehold):

Selv om Module Federation er bygget på Webpack, tillater det en viss grad av teknologiagnostisisme mellom forskjellige mikrofrontends. Én mikrofrontend kan være bygget med React, en annen med Vue.js, og en tredje med Angular, så lenge de er enige om hvordan de skal eksponere og konsumere moduler. For ekte kjøretidsdeling av komplekse rammeverk som React eller Vue, må man imidlertid være spesielt oppmerksom på hvordan disse rammeverkene initialiseres og deles for å unngå at flere instanser lastes og forårsaker konflikter.

Et globalt SaaS-selskap kan ha en kjerneplattform utviklet med ett rammeverk, og deretter spinne av spesialiserte funksjonsmoduler utviklet av forskjellige regionale team ved hjelp av andre rammeverk. Module Federation kan forenkle integrasjonen av disse ulike delene, forutsatt at de delte avhengighetene håndteres nøye.

5. Enklere versjonsadministrasjon:

Når en delt avhengighet må oppdateres, trenger bare den remote-en som eksponerer den, å bli oppdatert og distribuert på nytt. Alle konsumerende applikasjoner vil automatisk plukke opp den nye versjonen ved neste lasting. Dette forenkler prosessen med å administrere og oppdatere delt kode på tvers av hele applikasjonslandskapet.

Implementering av Module Federation: praktiske eksempler og strategier

La oss se på hvordan man setter opp og utnytter Module Federation i praksis. Vi vil bruke forenklede Webpack-konfigurasjoner for å illustrere kjernekonseptene.

Scenario: Dele et UI-komponentbibliotek

Anta at vi har to applikasjoner: en 'Produktkatalog' (remote) og et 'Bruker-dashboard' (host). Begge trenger å bruke en delt 'Button'-komponent fra et dedikert 'Delt UI'-bibliotek.

1. 'Delt UI'-biblioteket (Remote):

Denne applikasjonen vil eksponere sin 'Button'-komponent.

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

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'remoteEntry.js',
    path: path.resolve(__dirname, 'dist'),
    publicPath: 'http://localhost:3001/dist/', // URL hvor remote-tjenesten vil bli servert
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'sharedUI',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/components/Button.js', // Eksponer Button-komponenten
      },
      shared: {
        // Definer delte avhengigheter
        react: {
          singleton: true, // Sørg for at kun én instans av React lastes inn
        },
        'react-dom': {
          singleton: true,
        },
      },
    }),
  ],
  // ... andre webpack-konfigurasjoner (babel, devServer, etc.)
};

            

              
                Copy
              
            
          

src/components/Button.js:

            
import React from 'react';

const Button = ({ onClick, children }) => (
  
    {children}
  
);

export default Button;

            

              
                Copy
              
            
          

I dette oppsettet eksponerer 'Delt UI' sin Button-komponent og erklærer react og react-dom som delte avhengigheter med singleton: true for å sikre at de behandles som enkle instanser på tvers av konsumerende applikasjoner.

2. 'Produktkatalog'-applikasjonen (Remote):

Denne applikasjonen vil også trenge å konsumere den delte Button-komponenten og dele sine egne avhengigheter.

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

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'remoteEntry.js',
    path: path.resolve(__dirname, 'dist'),
    publicPath: 'http://localhost:3002/dist/', // URL hvor denne remote-tjenesten vil bli servert
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'productCatalog',
      filename: 'remoteEntry.js',
      exposes: {
        './ProductList': './src/components/ProductList.js', // Eksponer ProductList
      },
      remotes: {
        // Definer en remote den trenger å konsumere fra
        sharedUI: 'sharedUI@http://localhost:3001/dist/remoteEntry.js',
      },
      shared: {
        // Delte avhengigheter med samme versjon og singleton: true
        react: {
          singleton: true,
        },
        'react-dom': {
          singleton: true,
        },
      },
    }),
  ],
  // ... andre webpack-konfigurasjoner
};

            

              
                Copy
              
            
          

'Produktkatalogen' eksponerer nå sin ProductList-komponent og deklarerer sine egne remotes, og peker spesifikt til 'Delt UI'-applikasjonen. Den deklarerer også de samme delte avhengighetene.

3. 'Bruker-dashboard'-applikasjonen (Host):

Denne applikasjonen vil konsumere Button-komponenten fra 'Delt UI' og ProductList fra 'Produktkatalog'.

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

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist'),
    publicPath: 'http://localhost:3000/dist/', // URL hvor denne appens pakker serveres
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'userDashboard',
      remotes: {
        // Definer de remotes denne host-applikasjonen trenger
        sharedUI: 'sharedUI@http://localhost:3001/dist/remoteEntry.js',
        productCatalog: 'productCatalog@http://localhost:3002/dist/remoteEntry.js',
      },
      shared: {
        // Delte avhengigheter som må matche med remotes
        react: {
          singleton: true,
          import: 'react', // Spesifiser modulnavnet for import
        },
        'react-dom': {
          singleton: true,
          import: 'react-dom',
        },
      },
    }),
  ],
  // ... andre webpack-konfigurasjoner
};

            

              
                Copy
              
            
          

src/index.js for 'Bruker-dashboard':

            
import React, { Suspense } from 'react';
import ReactDOM from 'react-dom';

// Importer den delte Button-komponenten dynamisk
const RemoteButton = React.lazy(() => import('sharedUI/Button'));

// Importer ProductList-komponenten dynamisk
const RemoteProductList = React.lazy(() => import('productCatalog/ProductList'));

const App = () => {
  const handleClick = () => {
    alert('Knappen ble klikket fra delt UI!');
  };

  return (
    

      
Bruker-dashboard
      Laster knapp...
}>
        Klikk meg
      

      
Produkter
      Laster produkter...