npm install webpack webpack-cli webpack-dev-server --save-dev
            

              
                Copy
              
            
          

            const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
const path = require('path');

module.exports = {
 mode: 'development',
 devtool: 'source-map',
 entry: './src/index',
 output: {
 publicPath: 'http://localhost:3000/',
 },
 devServer: {
 port: 3000,
 hot: true,
 historyApiFallback: true, // For single page application routing
 },
 module: {
  rules: [
  {
   test: /\.(js|jsx)$/,
   exclude: /node_modules/,
   use: {
    loader: 'babel-loader',
    options: {
     presets: ['@babel/preset-env', '@babel/preset-react']
    }
   }
  },
  {
   test: /\.css$/,
   use: ['style-loader', 'css-loader']
  }
 ]
 },
 plugins: [
 new ModuleFederationPlugin({
 name: 'Host',
 filename: 'remoteEntry.js',
 remotes: {
 // Definer remotes her, f.eks., 'RemoteApp': 'RemoteApp@http://localhost:3001/remoteEntry.js'
 'RemoteApp': 'RemoteApp@http://localhost:3001/remoteEntry.js'
 },
 shared: {
 react: { singleton: true, requiredVersion: '^17.0.0' },
 'react-dom': { singleton: true, requiredVersion: '^17.0.0' },
 // Legg til andre delte avhengigheter her
 },
 }),
 // ... andre plugins
 ],
};

            

              
                Copy
              
            
          

            const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
const path = require('path');

module.exports = {
 mode: 'development',
 devtool: 'source-map',
 entry: './src/index',
 output: {
 publicPath: 'http://localhost:3001/',
 },
 devServer: {
 port: 3001,
 hot: true,
 historyApiFallback: true, // For single page application routing
 },
 module: {
  rules: [
  {
   test: /\.(js|jsx)$/,
   exclude: /node_modules/,
   use: {
    loader: 'babel-loader',
    options: {
     presets: ['@babel/preset-env', '@babel/preset-react']
    }
   }
  },
  {
   test: /\.css$/,
   use: ['style-loader', 'css-loader']
  }
 ]
 },
 plugins: [
 new ModuleFederationPlugin({
 name: 'RemoteApp',
 filename: 'remoteEntry.js',
 exposes: {
 './Widget': './src/Widget',
 // Legg til andre eksponerte moduler her
 },
 shared: {
 react: { singleton: true, requiredVersion: '^17.0.0' },
 'react-dom': { singleton: true, requiredVersion: '^17.0.0' },
 // Legg til andre delte avhengigheter her
 },
 }),
 // ... andre plugins
 ],
};

            

              
                Copy
              
            
          

            import React from 'react';

const Widget = () => {
 return (
  

  
Fjern-widget
  
Dette er en widget fra RemoteApp.
  
 );
};

export default Widget;

            

              
                Copy
              
            
          

            import React, { useState, useEffect } from 'react';

const RemoteWidget = React.lazy(() => import('RemoteApp/Widget'));

const App = () => {
 const [isWidgetLoaded, setIsWidgetLoaded] = useState(false);

 useEffect(() => {
  setIsWidgetLoaded(true);
 }, []);

 return (
  

  
Vertsapplikasjon
  
Dette er vertsapplikasjonen.
  {isWidgetLoaded ? (
   Laster inn widget...
}>
   
   
  ) : (
   
Laster...
  )}
  

Forklaring:

• React.lazy(() => import('RemoteApp/Widget')): Dette importerer dynamisk Widget-modulen fra RemoteApp. RemoteApp-navnet tilsvarer navnet definert i remotes-delen av vertens Webpack-konfigurasjon. Widget tilsvarer modulnavnet definert i exposes-delen av fjernapplikasjonens Webpack-konfigurasjon.
• React.Suspense: Dette brukes til å håndtere den asynkrone lastingen av fjernmodulen. fallback-propen spesifiserer en komponent som skal gjengis mens modulen lastes.

6. Kjør applikasjonene:

Start både verts- og fjernapplikasjonene med npm start (eller din foretrukne metode). Sørg for at fjernapplikasjonen kjører *før* vertsapplikasjonen.

Du skal nå se fjern-widgeten gjengitt i vertsapplikasjonen.

Avanserte teknikker for Module Federation

Utover det grunnleggende oppsettet, tilbyr Module Federation flere avanserte teknikker for å bygge sofistikerte mikro-frontend-arkitekturer.

1. Versjonskontroll og deling:

Å håndtere delte avhengigheter effektivt er avgjørende for å opprettholde stabilitet og unngå konflikter. Module Federation gir mekanismer for å spesifisere versjonsområder og singleton-forekomster av delte moduler. Ved å bruke shared-egenskapen i Webpack-konfigurasjonen kan du kontrollere hvordan delte moduler lastes og administreres.

Eksempel:

            shared: {
 react: { singleton: true, requiredVersion: '^17.0.0' },
 'react-dom': { singleton: true, requiredVersion: '^17.0.0' },
 lodash: { eager: true, version: '4.17.21' }
}

            

              
                Copy
              
            
          

• singleton: true: Sikrer at bare én forekomst av modulen lastes, noe som forhindrer duplisering og reduserer pakkestørrelsen. Dette er spesielt viktig for biblioteker som React og ReactDOM.
• requiredVersion: Spesifiserer versjonsområdet som applikasjonen krever. Webpack vil forsøke å laste en kompatibel versjon av modulen.
• eager: true: Laster modulen umiddelbart, i stedet for utsatt (lazy). Dette kan forbedre ytelsen i noen tilfeller, men kan også øke den initiale pakkestørrelsen.

2. Dynamisk Module Federation:

I stedet for å hardkode URL-ene til fjernapplikasjoner, kan du laste dem dynamisk fra en konfigurasjonsfil eller et API-endepunkt. Dette lar deg oppdatere mikro-frontend-arkitekturen uten å distribuere vertsapplikasjonen på nytt.

Eksempel:

Opprett en konfigurasjonsfil (f.eks. remote-config.json) som inneholder URL-ene til fjernapplikasjonene:

            {
 "RemoteApp": "http://localhost:3001/remoteEntry.js",
 "AnotherRemoteApp": "http://localhost:3002/remoteEntry.js"
}

            

              
                Copy
              
            
          

I vertsapplikasjonen, hent konfigurasjonsfilen og opprett remotes-objektet dynamisk:

            const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
const path = require('path');
const fs = require('fs');

module.exports = {
 // ... andre konfigurasjoner
 plugins: [
 new ModuleFederationPlugin({
 name: 'Host',
 filename: 'remoteEntry.js',
 remotes: new Promise(resolve => {
  fs.readFile(path.resolve(__dirname, 'remote-config.json'), (err, data) => {
  if (err) {
  console.error('Feil ved lesing av remote-config.json:', err);
  resolve({});
  } else {
  try {
  const remotesConfig = JSON.parse(data.toString());
  resolve(remotesConfig);
  } catch (parseError) {
  console.error('Feil ved parsing av remote-config.json:', parseError);
  resolve({});
  }
  }
  });
 }),
 shared: {
 react: { singleton: true, requiredVersion: '^17.0.0' },
 'react-dom': { singleton: true, requiredVersion: '^17.0.0' },
 // Legg til andre delte avhengigheter her
 },
 }),
 // ... andre plugins
 ],
};

            

              
                Copy
              
            
          

Viktig merknad: Vurder å bruke en mer robust metode for å hente fjernkonfigurasjonen i et produksjonsmiljø, for eksempel et API-endepunkt eller en dedikert konfigurasjonstjeneste. Eksemplet ovenfor bruker fs.readFile for enkelhets skyld, men dette er generelt ikke egnet for produksjonsdistribusjoner.

3. Egendefinerte lastestrategier:

Module Federation lar deg tilpasse hvordan fjernmoduler lastes. Du kan implementere egendefinerte lastestrategier for å optimalisere ytelsen eller håndtere spesifikke scenarier, som å laste moduler fra en CDN eller bruke en service worker.

Webpack eksponerer kroker (hooks) som lar deg avskjære og endre modulinnlastingsprosessen. Dette gir finkornet kontroll over hvordan fjernmoduler hentes og initialiseres.

4. Håndtering av CSS og stiler:

Å dele CSS og stiler mellom mikro-frontends kan være vanskelig. Module Federation støtter ulike tilnærminger for å håndtere stiler, inkludert:

• CSS-moduler: Bruk CSS-moduler for å innkapsle stiler i hver mikro-frontend, noe som forhindrer konflikter og sikrer konsistens.
• Styled Components: Benytt styled components eller andre CSS-in-JS-biblioteker for å administrere stiler i selve komponentene.
• Globale stiler: Last inn globale stiler fra et delt bibliotek eller CDN. Vær forsiktig med denne tilnærmingen, da den kan føre til konflikter hvis stiler ikke er riktig navngitt (namespaced).

Eksempel med CSS-moduler:

Konfigurer Webpack til å bruke CSS-moduler:

            module: {
 rules: [
 {
 test: /\.module\.css$/,
 use: [
 'style-loader',
 {
 loader: 'css-loader',
 options: {
 modules: {
 localIdentName: '[name]__[local]--[hash:base64:5]',
 },
 importLoaders: 1,
 },
 },
 'postcss-loader',
 ],
 },
 // ... andre regler
],
}

            

              
                Copy
              
            
          

Importer CSS-moduler i komponentene dine:

            import React from 'react';
import styles from './Widget.module.css';

const Widget = () => {
 return (
  

  
Fjern-widget
  
Dette er en widget fra RemoteApp.
  
 );
};

export default Widget;

            

              
                Copy
              
            
          

5. Kommunikasjon mellom mikro-frontends:

Mikro-frontends må ofte kommunisere med hverandre for å utveksle data eller utløse handlinger. Det er flere måter å oppnå dette på:

• Delte hendelser: Bruk en global hendelsesbuss (event bus) for å publisere og abonnere på hendelser. Dette lar mikro-frontends kommunisere asynkront uten direkte avhengigheter.
• Egendefinerte hendelser: Benytt egendefinerte DOM-hendelser for kommunikasjon mellom mikro-frontends på samme side.
• Delt tilstandshåndtering: Bruk et delt bibliotek for tilstandshåndtering (f.eks. Redux, Zustand) for å sentralisere tilstand og lette datadeling.
• Direkte modulimport: Hvis mikro-frontends er tett koblet, kan du importere moduler direkte fra hverandre ved hjelp av Module Federation. Denne tilnærmingen bør imidlertid brukes med måte for å unngå å skape avhengigheter som undergraver fordelene med mikro-frontends.
• API-er og tjenester: Mikro-frontends kan kommunisere med hverandre gjennom API-er og tjenester, noe som gir løs kobling og større fleksibilitet. Dette er spesielt nyttig når mikro-frontends er distribuert på forskjellige domener eller har forskjellige sikkerhetskrav.

Fordeler med å bruke Module Federation for mikro-frontends

• Forbedret skalerbarhet: Mikro-frontends kan skaleres uavhengig, slik at du kan tildele ressurser der de trengs mest.
• Økt vedlikeholdbarhet: Mindre kodebaser er lettere å forstå og vedlikeholde, noe som reduserer risikoen for feil og forbedrer utviklerproduktiviteten.
• Raskere distribusjonssykluser: Mikro-frontends kan distribueres uavhengig, noe som gir raskere iterasjonssykluser og raskere utgivelse av nye funksjoner.
• Teknologisk mangfold: Team kan velge teknologiene og rammeverkene som passer best for deres behov, noe som fremmer innovasjon og tillater bruk av spesialisert kompetanse.
• Forbedret teamautonomi: Hver mikro-frontend eies av et dedikert team, noe som fremmer eierskap og ansvarlighet.
• Forenklet onboarding: Nye utviklere kan raskt sette seg inn i mindre, mer håndterbare kodebaser.

Utfordringer med å bruke Module Federation

• Økt kompleksitet: Mikro-frontend-arkitekturer kan være mer komplekse enn tradisjonelle monolittiske arkitekturer, og krever nøye planlegging og koordinering.
• Håndtering av delte avhengigheter: Å håndtere delte avhengigheter kan være utfordrende, spesielt når forskjellige mikro-frontends bruker forskjellige versjoner av det samme biblioteket.
• Kommunikasjonsoverhead: Kommunikasjon mellom mikro-frontends kan introdusere overhead og forsinkelse.
• Integrasjonstesting: Testing av integrasjonen av mikro-frontends kan være mer komplisert enn å teste en monolittisk applikasjon.
• Initiell oppsettsoverhead: Konfigurering av Module Federation og oppsett av den innledende infrastrukturen kan kreve betydelig innsats.

Eksempler og bruksområder fra den virkelige verden

Module Federation brukes av et økende antall selskaper for å bygge store, komplekse webapplikasjoner. Her er noen eksempler og bruksområder fra den virkelige verden:

• E-handelsplattformer: Store e-handelsplattformer bruker ofte mikro-frontends for å administrere forskjellige deler av nettstedet, som produktkatalogen, handlekurven og betalingsprosessen. For eksempel kan en tysk forhandler bruke en separat mikro-frontend for å vise produkter på tysk, mens en fransk forhandler bruker en annen mikro-frontend for franske produkter, begge integrert i en enkelt vertsapplikasjon.
• Finansinstitusjoner: Banker og finansinstitusjoner bruker mikro-frontends for å bygge komplekse bankapplikasjoner, som nettbankportaler, investeringsplattformer og handelssystemer. En global bank kan ha team i forskjellige land som utvikler mikro-frontends for forskjellige regioner, hver skreddersydd for lokale reguleringer og kundepreferanser.
• Innholdsstyringssystemer (CMS): CMS-plattformer kan bruke mikro-frontends for å la brukere tilpasse utseendet og funksjonaliteten på nettstedene sine. For eksempel kan et kanadisk selskap som tilbyr CMS-tjenester la brukere legge til eller fjerne forskjellige mikro-frontends (widgets) på nettstedet sitt for å tilpasse funksjonaliteten.
• Dashboards og analyseplattformer: Mikro-frontends er godt egnet for å bygge dashboards og analyseplattformer, der forskjellige team kan bidra med forskjellige widgets og visualiseringer.
• Helseapplikasjoner: Helsetjenesteleverandører bruker mikro-frontends for å bygge pasientportaler, elektroniske pasientjournalsystemer (EPJ) og telemedisinplattformer.

Beste praksis for implementering av Module Federation

For å sikre suksessen til din Module Federation-implementering, følg disse beste praksisene:

• Planlegg nøye: Før du starter, planlegg mikro-frontend-arkitekturen din nøye og definer klare grenser mellom de forskjellige applikasjonene.
• Etabler tydelige kommunikasjonskanaler: Etabler tydelige kommunikasjonskanaler mellom teamene som er ansvarlige for de forskjellige mikro-frontendene.
• Automatiser distribusjon: Automatiser distribusjonsprosessen for å sikre at mikro-frontends kan distribueres raskt og pålitelig.
• Overvåk ytelse: Overvåk ytelsen til mikro-frontend-arkitekturen din for å identifisere og adressere eventuelle flaskehalser.
• Implementer robust feilhåndtering: Implementer robust feilhåndtering for å forhindre kaskadefeil og sikre at applikasjonen forblir robust.
• Bruk en konsekvent kodestil: Håndhev en konsekvent kodestil på tvers av alle mikro-frontends for å forbedre vedlikeholdbarheten.
• Dokumenter alt: Dokumenter arkitekturen, avhengighetene og kommunikasjonsprotokollene dine for å sikre at systemet er godt forstått og vedlikeholdbart.
• Vurder sikkerhetsimplikasjoner: Vurder nøye sikkerhetsimplikasjonene av din mikro-frontend-arkitektur og implementer passende sikkerhetstiltak. Sørg for overholdelse av globale personvernregler som GDPR og CCPA.

Konklusjon

JavaScript Module Federation med Webpack 5 gir en kraftig og fleksibel måte å bygge mikro-frontend-arkitekturer på. Ved å bryte ned store applikasjoner i mindre, uavhengig distribuerbare enheter, kan du forbedre skalerbarhet, vedlikeholdbarhet og teamautonomi. Selv om det er utfordringer knyttet til implementering av mikro-frontends, veier fordelene ofte opp for kostnadene, spesielt for komplekse webapplikasjoner. Ved å følge beste praksis som er skissert i denne guiden, kan du lykkes med å utnytte Module Federation til å bygge robuste og skalerbare mikro-frontend-arkitekturer som møter behovene til din organisasjon og brukere over hele verden.