JavaScript Module Federation: Frigør Kraften i Runtime Sharing for Globale Applikationer

I nutidens hastigt udviklende digitale landskab er det altafgørende at bygge skalerbare, vedligeholdelsesvenlige og samarbejdsorienterede webapplikationer. Efterhånden som udviklingsteams vokser, og applikationer bliver mere komplekse, bliver behovet for effektiv kodedeling og afkobling stadig mere kritisk. JavaScript Module Federation, en banebrydende funktion introduceret med Webpack 5, tilbyder en kraftfuld løsning ved at muliggøre deling af kode i realtid (runtime sharing) mellem uafhængigt implementerede applikationer. Dette blogindlæg dykker ned i kernekoncepterne i Module Federation med fokus på dets runtime-delingsfunktioner og undersøger, hvordan det kan revolutionere den måde, globale teams bygger og administrerer deres webapplikationer på.

Webudviklingens Udviklende Landskab og Behovet for Deling

Historisk set involverede webudvikling ofte monolitiske applikationer, hvor al kode befandt sig i en enkelt kodebase. Selvom denne tilgang kan være passende for mindre projekter, bliver den hurtigt uhåndterlig, når applikationer skalerer. Afhængigheder bliver sammenfiltrede, byggetider øges, og implementering af opdateringer kan være en kompleks og risikabel affære. Fremkomsten af microservices i backend-udvikling banede vejen for lignende arkitektoniske mønstre på frontend, hvilket førte til fremkomsten af microfrontends.

Microfrontends sigter mod at nedbryde store, komplekse frontend-applikationer i mindre, uafhængige og implementerbare enheder. Dette giver forskellige teams mulighed for at arbejde autonomt på forskellige dele af applikationen, hvilket fører til hurtigere udviklingscyklusser og forbedret team-autonomi. En betydelig udfordring i microfrontend-arkitekturer har dog altid været effektiv kodedeling. Duplikering af fælles biblioteker, UI-komponenter eller hjælpefunktioner på tværs af flere microfrontends fører til:

• Forøgede Bundle-størrelser: Hver applikation bærer sin egen kopi af delte afhængigheder, hvilket oppuster den samlede downloadstørrelse for brugerne.
• Inkonsistente Afhængigheder: Forskellige microfrontends kan ende med at bruge forskellige versioner af det samme bibliotek, hvilket fører til kompatibilitetsproblemer og uforudsigelig adfærd.
• Vedligeholdelsesomkostninger: Opdatering af delt kode kræver ændringer på tværs af flere applikationer, hvilket øger risikoen for fejl og bremser implementeringen.
• Spildte Ressourcer: At downloade den samme kode flere gange er ineffektivt for både klienten og serveren.

Module Federation adresserer direkte disse udfordringer ved at introducere en mekanisme til ægte kodedeling i runtime.

Hvad er JavaScript Module Federation?

JavaScript Module Federation, primært implementeret gennem Webpack 5, er en funktion i et bygningsværktøj, der giver JavaScript-applikationer mulighed for dynamisk at indlæse kode fra andre applikationer i runtime. Det muliggør oprettelsen af flere uafhængige applikationer, der kan dele kode og afhængigheder uden at kræve et monorepo eller en kompleks byggetids-integrationsproces.

Kerneideen er at definere "remotes" (applikationer, der eksponerer moduler) og "hosts" (applikationer, der forbruger moduler fra remotes). Disse remotes og hosts kan implementeres uafhængigt, hvilket giver betydelig fleksibilitet i håndteringen af komplekse applikationer og muliggør forskellige arkitektoniske mønstre.

Forståelse af Runtime Sharing: Kernen i Module Federation

Runtime-deling er hjørnestenen i Module Federations styrke. I modsætning til traditionelle teknikker til code-splitting eller delt afhængighedsstyring, der ofte sker på byggetidspunktet, giver Module Federation applikationer mulighed for at opdage og indlæse moduler fra andre applikationer direkte i brugerens browser. Det betyder, at et fælles bibliotek, et delt UI-komponentbibliotek eller endda et funktionsmodul kan indlæses én gang af én applikation og derefter gøres tilgængeligt for andre applikationer, der har brug for det.

Lad os se nærmere på, hvordan det fungerer:

Nøglekoncepter:

• Exposes: En applikation kan 'eksponere' visse moduler (f.eks. en React-komponent, en hjælpefunktion), som andre applikationer kan forbruge. Disse eksponerede moduler bundtes i en container, der kan indlæses fjernt.
• Remotes: En applikation, der eksponerer moduler, betragtes som en 'remote'. Den eksponerer sine moduler via en delt konfiguration.
• Consumes: En applikation, der skal bruge moduler fra en remote, er en 'consumer' eller 'host'. Den konfigurerer sig selv til at vide, hvor den kan finde de fjerne applikationer, og hvilke moduler den skal indlæse.
• Shared Modules: Module Federation giver mulighed for at definere delte moduler. Når flere applikationer forbruger det samme delte modul, indlæses og deles kun én instans af det modul mellem dem. Dette er et kritisk aspekt for at optimere bundle-størrelser og forhindre afhængighedskonflikter.

Mekanismen:

Når en host-applikation har brug for et modul fra en remote, anmoder den om det fra remotens container. Remote-containeren indlæser derefter dynamisk det anmodede modul. Hvis modulet allerede er indlæst af en anden forbrugende applikation, vil det blive delt. Denne dynamiske indlæsning og deling sker problemfrit i runtime, hvilket giver en yderst effektiv måde at håndtere afhængigheder på.

Fordele ved Module Federation for Global Udvikling

Fordelene ved at anvende Module Federation til at bygge globale applikationer er betydelige og vidtrækkende:

1. Forbedret Skalerbarhed og Vedligeholdelse:

Ved at nedbryde en stor applikation i mindre, uafhængige microfrontends fremmer Module Federation i sagens natur skalerbarhed. Teams kan arbejde på individuelle microfrontends uden at påvirke andre, hvilket muliggør parallel udvikling og uafhængige implementeringer. Dette reducerer den kognitive byrde forbundet med at administrere en massiv kodebase og gør applikationen mere vedligeholdelsesvenlig over tid.

2. Optimerede Bundle-størrelser og Ydeevne:

Den mest betydningsfulde fordel ved runtime-deling er reduktionen i den samlede downloadstørrelse. I stedet for at hver applikation duplikerer fælles biblioteker (som React, Lodash eller et brugerdefineret UI-komponentbibliotek), indlæses disse afhængigheder én gang og deles. Dette fører til:

• Hurtigere Indledende Indlæsningstider: Brugere downloader mindre kode, hvilket resulterer i en hurtigere indledende gengivelse af applikationen.
• Forbedret Efterfølgende Navigation: Når man navigerer mellem microfrontends, der deler afhængigheder, genbruges de allerede indlæste moduler, hvilket fører til en hurtigere brugeroplevelse.
• Reduceret Serverbelastning: Mindre data overføres fra serveren, hvilket potentielt kan sænke hostingomkostningerne.

Overvej en global e-handelsplatform med separate sektioner for produktlister, brugerkonti og checkout. Hvis hver sektion er en separat microfrontend, men de alle er afhængige af et fælles UI-komponentbibliotek til knapper, formularer og navigation, sikrer Module Federation, at dette bibliotek kun indlæses én gang, uanset hvilken sektion brugeren besøger først.

3. Øget Team-autonomi og Samarbejde:

Module Federation giver forskellige teams, potentielt placeret i forskellige globale regioner, mulighed for at arbejde uafhængigt på deres respektive microfrontends. De kan vælge deres egne teknologistakke (inden for rimelighedens grænser for at opretholde en vis grad af konsistens) og implementeringsplaner. Denne autonomi fremmer hurtigere innovation og reducerer kommunikationsomkostningerne. Evnen til at dele fælles kode opmuntrer dog også til samarbejde, da teams kan bidrage til og drage fordel af delte biblioteker og komponenter.

Forestil dig en global finansiel institution med separate teams i Europa, Asien og Nordamerika, der er ansvarlige for forskellige produkttilbud. Module Federation giver hvert team mulighed for at udvikle deres specifikke funktioner, mens de udnytter en fælles autentificeringstjeneste eller et delt diagrambibliotek udviklet af et centralt team. Dette fremmer genanvendelighed og sikrer konsistens på tværs af forskellige produktlinjer.

4. Teknologiagnosticisme (med forbehold):

Selvom Module Federation er bygget på Webpack, tillader det en vis grad af teknologiagnosticisme mellem forskellige microfrontends. En microfrontend kan være bygget med React, en anden med Vue.js og en tredje med Angular, så længe de er enige om, hvordan man eksponerer og forbruger moduler. For ægte runtime-deling af komplekse frameworks som React eller Vue, skal man dog være særligt opmærksom på, hvordan disse frameworks initialiseres og deles for at undgå, at flere instanser indlæses og forårsager konflikter.

En global SaaS-virksomhed kan have en kerneplatform udviklet med ét framework og derefter udskille specialiserede funktionsmoduler udviklet af forskellige regionale teams ved hjælp af andre frameworks. Module Federation kan lette integrationen af disse forskellige dele, forudsat at de delte afhængigheder håndteres omhyggeligt.

5. Nemmere Versionsstyring:

Når en delt afhængighed skal opdateres, er det kun den remote, der eksponerer den, der skal opdateres og genimplementeres. Alle forbrugende applikationer vil automatisk hente den nye version ved deres næste indlæsning. Dette forenkler processen med at administrere og opdatere delt kode på tværs af hele applikationslandskabet.

Implementering af Module Federation: Praktiske Eksempler og Strategier

Lad os se på, hvordan man opsætter og udnytter Module Federation i praksis. Vi vil bruge forenklede Webpack-konfigurationer til at illustrere kernekoncepterne.

Scenarie: Deling af et UI-komponentbibliotek

Antag, at vi har to applikationer: et 'Produktkatalog' (remote) og et 'Bruger-dashboard' (host). Begge skal bruge en delt 'Button'-komponent fra et dedikeret 'Shared UI'-bibliotek.

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

Denne applikation 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 where the remote will be served
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'sharedUI',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/components/Button.js', // Expose Button component
      },
      shared: {
        // Define shared dependencies
        react: {
          singleton: true, // Ensure only one instance of React is loaded
        },
        'react-dom': {
          singleton: true,
        },
      },
    }),
  ],
  // ... other webpack configurations (babel, devServer, etc.)
};

            

              
                Copy
              
            
          

src/components/Button.js:

            
import React from 'react';

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

export default Button;

            

              
                Copy
              
            
          

I denne opsætning eksponerer 'Shared UI' sin Button-komponent og erklærer react og react-dom som delte afhængigheder med singleton: true for at sikre, at de behandles som enkeltstående instanser på tværs af forbrugende applikationer.

2. 'Produktkatalog'-applikationen (Remote):

Denne applikation skal også forbruge den delte Button-komponent og dele sine egne afhængigheder.

            
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 where this remote will be served
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'productCatalog',
      filename: 'remoteEntry.js',
      exposes: {
        './ProductList': './src/components/ProductList.js', // Expose ProductList
      },
      remotes: {
        // Define a remote it needs to consume from
        sharedUI: 'sharedUI@http://localhost:3001/dist/remoteEntry.js',
      },
      shared: {
        // Shared dependencies with the same version and singleton: true
        react: {
          singleton: true,
        },
        'react-dom': {
          singleton: true,
        },
      },
    }),
  ],
  // ... other webpack configurations
};

            

              
                Copy
              
            
          

'Produktkataloget' eksponerer nu sin ProductList-komponent og erklærer sine egne remotes, specifikt pegende på 'Shared UI'-applikationen. Det erklærer også de samme delte afhængigheder.

3. 'Bruger-dashboard'-applikationen (Host):

Denne applikation vil forbruge Button-komponenten fra 'Shared 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 where this app's bundles are served
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'userDashboard',
      remotes: {
        // Define the remotes this host application needs
        sharedUI: 'sharedUI@http://localhost:3001/dist/remoteEntry.js',
        productCatalog: 'productCatalog@http://localhost:3002/dist/remoteEntry.js',
      },
      shared: {
        // Shared dependencies that must match the remotes
        react: {
          singleton: true,
          import: 'react', // Specify the module name for import
        },
        'react-dom': {
          singleton: true,
          import: 'react-dom',
        },
      },
    }),
  ],
  // ... other webpack configurations
};

            

              
                Copy
              
            
          

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

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

// Dynamically import the shared Button component
const RemoteButton = React.lazy(() => import('sharedUI/Button'));

// Dynamically import the ProductList component
const RemoteProductList = React.lazy(() => import('productCatalog/ProductList'));

const App = () => {
  const handleClick = () => {
    alert('Button clicked from shared UI!');
  };

  return (
    

      
User Dashboard
      Loading Button...
}>
        Click Me
      

      
Products
      Loading Products...