JavaScript Module Federation: Lås upp kraften i körtidsdelning för globala applikationer

I dagens snabbt föränderliga digitala landskap är det avgörande att bygga skalbara, underhållbara och kollaborativa webbapplikationer. När utvecklingsteam växer och applikationer blir mer komplexa blir behovet av effektiv koddelning och frikoppling allt viktigare. JavaScript Module Federation, en banbrytande funktion som introducerades med Webpack 5, erbjuder en kraftfull lösning genom att möjliggöra körtidsdelning av kod mellan oberoende driftsatta applikationer. Detta blogginlägg fördjupar sig i kärnkoncepten för Module Federation, med fokus på dess funktioner för körtidsdelning, och utforskar hur det kan revolutionera sättet globala team bygger och hanterar sina webbapplikationer.

Webbutvecklingens föränderliga landskap och behovet av delning

Historiskt sett innebar webbutveckling ofta monolitiska applikationer där all kod fanns i en enda kodbas. Även om detta tillvägagångssätt kan vara lämpligt för mindre projekt, blir det snabbt ohanterligt när applikationer skalas. Beroenden blir sammanflätade, byggtiderna ökar och att driftsätta uppdateringar kan vara ett komplext och riskfyllt företag. Framväxten av microservices i backend-utveckling banade väg för liknande arkitekturmönster på frontend, vilket ledde till uppkomsten av mikrofrontends.

Mikrofrontends syftar till att bryta ner stora, komplexa frontend-applikationer i mindre, oberoende och driftsättningsbara enheter. Detta gör det möjligt för olika team att arbeta på olika delar av applikationen autonomt, vilket leder till snabbare utvecklingscykler och förbättrad teamautonomi. En betydande utmaning i mikrofrontend-arkitekturer har dock alltid varit effektiv koddelning. Att duplicera vanliga bibliotek, UI-komponenter eller hjälpfunktioner över flera mikrofrontends leder till:

• Ökade paketstorlekar: Varje applikation bär på sin egen kopia av delade beroenden, vilket blåser upp den totala nedladdningsstorleken för användare.
• Inkonsistenta beroenden: Olika mikrofrontends kan använda olika versioner av samma bibliotek, vilket leder till kompatibilitetsproblem och oförutsägbart beteende.
• Underhållsarbete: Att uppdatera delad kod kräver ändringar i flera applikationer, vilket ökar risken för fel och saktar ner driftsättningen.
• Slöseri med resurser: Att ladda ner samma kod flera gånger är ineffektivt för både klienten och servern.

Module Federation adresserar dessa utmaningar direkt genom att introducera en mekanism för att verkligen dela kod vid körtid.

Vad är JavaScript Module Federation?

JavaScript Module Federation, huvudsakligen implementerat genom Webpack 5, är en funktion i byggverktyg som låter JavaScript-applikationer dynamiskt ladda kod från andra applikationer vid körtid. Det möjliggör skapandet av flera oberoende applikationer som kan dela kod och beroenden utan att kräva ett monorepo eller en komplex integrationsprocess vid byggtid.

Kärnkonceptet är att definiera "remotes" (applikationer som exponerar moduler) och "hosts" (applikationer som konsumerar moduler från remotes). Dessa remotes och hosts kan driftsättas oberoende av varandra, vilket erbjuder betydande flexibilitet i hanteringen av komplexa applikationer och möjliggör olika arkitekturmönster.

Att förstå körtidsdelning: Kärnan i Module Federation

Körtidsdelning är hörnstenen i Module Federations kraft. Till skillnad från traditionell koddelning eller tekniker för hantering av delade beroenden som ofta sker vid byggtid, låter Module Federation applikationer upptäcka och ladda moduler från andra applikationer direkt i användarens webbläsare. Detta innebär att ett vanligt bibliotek, ett delat UI-komponentbibliotek eller till och med en funktionsmodul kan laddas en gång av en applikation och sedan göras tillgänglig för andra applikationer som behöver den.

Låt oss bryta ner hur detta fungerar:

Nyckelkoncept:

• Exposes: En applikation kan 'exponera' vissa moduler (t.ex. en React-komponent, en hjälpfunktion) som andra applikationer kan konsumera. Dessa exponerade moduler paketeras i en container som kan laddas på distans.
• Remotes: En applikation som exponerar moduler betraktas som en 'remote'. Den exponerar sina moduler via en delad konfiguration.
• Consumes: En applikation som behöver använda moduler från en remote är en 'consumer' eller 'host'. Den konfigurerar sig själv för att veta var den ska hitta fjärrapplikationerna och vilka moduler som ska laddas.
• Shared Modules: Module Federation tillåter definition av delade moduler. När flera applikationer konsumerar samma delade modul laddas endast en instans av den modulen och delas mellan dem. Detta är en kritisk aspekt för att optimera paketstorlekar och förhindra beroendekonflikter.

Mekanismen:

När en host-applikation behöver en modul från en remote, begär den den från remotens container. Remotens container laddar sedan dynamiskt den begärda modulen. Om modulen redan är laddad av en annan konsumerande applikation kommer den att delas. Denna dynamiska laddning och delning sker sömlöst vid körtid, vilket ger ett mycket effektivt sätt att hantera beroenden.

Fördelar med Module Federation för global utveckling

Fördelarna med att anamma Module Federation för att bygga globala applikationer är betydande och långtgående:

1. Förbättrad skalbarhet och underhållbarhet:

Genom att bryta ner en stor applikation i mindre, oberoende mikrofrontends främjar Module Federation i sig skalbarhet. Team kan arbeta på enskilda mikrofrontends utan att påverka andra, vilket möjliggör parallell utveckling och oberoende driftsättningar. Detta minskar den kognitiva belastningen som är förknippad med att hantera en massiv kodbas och gör applikationen mer underhållbar över tid.

2. Optimerade paketstorlekar och prestanda:

Den mest betydande fördelen med körtidsdelning är minskningen av den totala nedladdningsstorleken. Istället för att varje applikation duplicerar vanliga bibliotek (som React, Lodash eller ett anpassat UI-komponentbibliotek), laddas dessa beroenden en gång och delas. Detta leder till:

• Snabbare initiala laddningstider: Användare laddar ner mindre kod, vilket resulterar i en snabbare initial rendering av applikationen.
• Förbättrad efterföljande navigering: När man navigerar mellan mikrofrontends som delar beroenden, återanvänds de redan laddade modulerna, vilket leder till en rappare användarupplevelse.
• Minskad serverbelastning: Mindre data överförs från servern, vilket potentiellt sänker hostingkostnaderna.

Tänk på en global e-handelsplattform med distinkta sektioner för produktlistor, användarkonton och kassan. Om varje sektion är en separat mikrofrontend, men alla förlitar sig på ett gemensamt UI-komponentbibliotek för knappar, formulär och navigering, säkerställer Module Federation att detta bibliotek endast laddas en gång, oavsett vilken sektion användaren besöker först.

3. Ökad teamautonomi och samarbete:

Module Federation ger olika team, potentiellt belägna i olika globala regioner, möjlighet att arbeta oberoende på sina respektive mikrofrontends. De kan välja sina egna teknikstackar (inom rimliga gränser, för att bibehålla en viss nivå av konsistens) och driftsättningsscheman. Denna autonomi främjar snabbare innovation och minskar kommunikationsomkostnader. Men förmågan att dela gemensam kod uppmuntrar också samarbete, eftersom team kan bidra till och dra nytta av delade bibliotek och komponenter.

Föreställ dig en global finansiell institution med separata team i Europa, Asien och Nordamerika som ansvarar för olika produkterbjudanden. Module Federation gör det möjligt för varje team att utveckla sina specifika funktioner samtidigt som de utnyttjar en gemensam autentiseringstjänst eller ett delat diagrambibliotek som utvecklats av ett centralt team. Detta främjar återanvändbarhet och säkerställer konsistens över olika produktlinjer.

4. Teknikagnosticism (med förbehåll):

Även om Module Federation är byggt på Webpack, tillåter det en viss grad av teknikagnosticism mellan olika mikrofrontends. En mikrofrontend kan byggas med React, en annan med Vue.js och en tredje med Angular, så länge de är överens om hur moduler ska exponeras och konsumeras. Men för verklig körtidsdelning av komplexa ramverk som React eller Vue måste särskild uppmärksamhet ägnas åt hur dessa ramverk initialiseras och delas för att undvika att flera instanser laddas och orsakar konflikter.

Ett globalt SaaS-företag kan ha en kärnplattform utvecklad med ett ramverk och sedan skapa specialiserade funktionsmoduler utvecklade av olika regionala team med andra ramverk. Module Federation kan underlätta integrationen av dessa olika delar, förutsatt att de delade beroendena hanteras noggrant.

5. Enklare versionshantering:

När ett delat beroende behöver uppdateras behöver endast den remote som exponerar det uppdateras och driftsättas på nytt. Alla konsumerande applikationer kommer automatiskt att plocka upp den nya versionen vid nästa laddning. Detta förenklar processen att hantera och uppdatera delad kod över hela applikationslandskapet.

Implementering av Module Federation: Praktiska exempel och strategier

Låt oss titta på hur man konfigurerar och utnyttjar Module Federation i praktiken. Vi kommer att använda förenklade Webpack-konfigurationer för att illustrera kärnkoncepten.

Scenario: Dela ett UI-komponentbibliotek

Antag att vi har två applikationer: en 'Produktkatalog' (remote) och en 'Användarpanel' (host). Båda behöver använda en delad 'Button'-komponent från ett dedikerat 'Shared UI'-bibliotek.

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

Denna applikation kommer att exponera 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 denna konfiguration exponerar 'Shared UI' sin Button-komponent och deklarerar react och react-dom som delade beroenden med singleton: true för att säkerställa att de behandlas som enstaka instanser över konsumerande applikationer.

2. 'Produktkatalog'-applikationen (Remote):

Denna applikation kommer också att behöva konsumera den delade Button-komponenten och dela sina egna beroenden.

            
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
              
            
          

'Produktkatalogen' exponerar nu sin ProductList-komponent och deklarerar sina egna remotes, specifikt pekande på 'Shared UI'-applikationen. Den deklarerar också samma delade beroenden.

3. 'Användarpanel'-applikationen (Host):

Denna applikation kommer att konsumera Button-komponenten från 'Shared UI' och ProductList från '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 för 'Användarpanel':

            
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...