16 augusti 2025Svenska

Frigör kraften i mikro-frontends med JavaScript Module Federation i Webpack 5. Lär dig bygga skalbara, underhållbara och oberoende webbapplikationer.

JavaScript Module Federation med Webpack 5: En omfattande guide till mikro-frontends

I det ständigt föränderliga landskapet för webbutveckling kan det vara en skrämmande uppgift att bygga stora och komplexa applikationer. Traditionella monolitiska arkitekturer leder ofta till ökad utvecklingstid, flaskhalsar vid driftsättning och utmaningar med att upprätthålla kodkvaliteten. Mikro-frontends har framträtt som ett kraftfullt arkitektoniskt mönster för att hantera dessa utmaningar, vilket gör att team kan bygga och driftsätta oberoende delar av en större webbapplikation. En av de mest lovande teknologierna för att implementera mikro-frontends är JavaScript Module Federation, introducerad i Webpack 5.

Vad är mikro-frontends?

Mikro-frontends är en arkitektonisk stil där en frontend-applikation delas upp i mindre, oberoende enheter som kan utvecklas, testas och driftsättas autonomt av olika team. Varje mikro-frontend ansvarar för en specifik affärsdomän eller funktion, och de komponeras samman vid körtid för att bilda det kompletta användargränssnittet.

Tänk på det som ett företag: istället för att ha ett jättestort utvecklingsteam har du flera mindre team som fokuserar på specifika områden. Varje team kan arbeta självständigt, vilket möjliggör snabbare utvecklingscykler och enklare underhåll. Tänk på en stor e-handelsplattform som Amazon; olika team kan hantera produktkatalogen, varukorgen, kassaprocessen och användarkontohanteringen. Dessa skulle alla kunna vara oberoende mikro-frontends.

Fördelar med mikro-frontends:

Oberoende driftsättningar: Team kan driftsätta sina mikro-frontends oberoende, utan att påverka andra delar av applikationen. Detta minskar risken vid driftsättning och möjliggör snabbare releasecykler.
Teknikagnostiskt: Olika mikro-frontends kan byggas med olika teknologier eller ramverk (t.ex. React, Angular, Vue.js). Detta gör att team kan välja den bästa tekniken för sina specifika behov och gradvis anamma nya teknologier utan att behöva skriva om hela applikationen. Tänk dig ett team som använder React för produktkatalogen, ett annat som använder Vue.js för marknadsföringssidor, och ett tredje som använder Angular för kassaprocessen.
Förbättrad teamautonomi: Team har fullt ägandeskap över sina mikro-frontends, vilket leder till ökad autonomi, snabbare beslutsfattande och förbättrad utvecklarproduktivitet.
Ökad skalbarhet: Mikro-frontends gör det möjligt att skala din applikation horisontellt genom att driftsätta enskilda mikro-frontends på olika servrar.
Återanvändbarhet av kod: Delade komponenter och bibliotek kan enkelt delas mellan mikro-frontends.
Lättare att underhålla: Mindre kodbaser är generellt lättare att förstå, underhålla och felsöka.

Utmaningar med mikro-frontends:

Ökad komplexitet: Att hantera flera mikro-frontends kan lägga till komplexitet i den övergripande arkitekturen, särskilt när det gäller kommunikation, state-hantering och driftsättning.
Prestanda-overhead: Att ladda flera mikro-frontends kan introducera prestanda-overhead, särskilt om de inte är korrekt optimerade.
Genomgående ansvarsområden (Cross-Cutting Concerns): Att hantera genomgående ansvarsområden som autentisering, auktorisering och temahantering kan vara utmanande i en mikro-frontend-arkitektur.
Driftmässig overhead: Kräver mogna DevOps-praxis och infrastruktur för att hantera driftsättning och övervakning av flera mikro-frontends.

Vad är JavaScript Module Federation?

JavaScript Module Federation är en funktion i Webpack 5 som låter dig dela kod mellan separat kompilerade JavaScript-applikationer vid körtid. Det gör det möjligt att exponera delar av din applikation som "moduler" som kan konsumeras av andra applikationer, utan att behöva publicera till ett centralt arkiv som npm.

Tänk på Module Federation som ett sätt att skapa ett federerat ekosystem av applikationer, där varje applikation kan bidra med sin egen funktionalitet och konsumera funktionalitet från andra applikationer. Detta eliminerar behovet av beroenden vid byggtid och möjliggör verkligt oberoende driftsättningar.

Till exempel kan ett team för ett designsystem exponera UI-komponenter som moduler, och olika applikationsteam kan konsumera dessa komponenter direkt från designsystemets applikation, utan att behöva installera dem som npm-paket. När designsystemteamet uppdaterar komponenterna, reflekteras ändringarna automatiskt i alla konsumerande applikationer.

Nyckelkoncept i Module Federation:

Host: Huvudapplikationen som konsumerar fjärrmoduler.
Remote: En applikation som exponerar moduler för att konsumeras av andra applikationer.
Shared Modules (Delade moduler): Moduler som delas mellan host- och remote-applikationer (t.ex. React, Lodash). Module Federation kan automatiskt hantera versionering och deduplicering av delade moduler för att säkerställa att endast en version av varje modul laddas.
Exposed Modules (Exponerade moduler): Specifika moduler från en remote-applikation som görs tillgängliga för konsumtion av andra applikationer.
RemoteEntry.js: En fil genererad av Webpack som innehåller metadata om de exponerade modulerna i en remote-applikation. Host-applikationen använder denna fil för att upptäcka och ladda fjärrmodulerna.

Konfigurera Module Federation med Webpack 5: En praktisk guide

Låt oss gå igenom ett praktiskt exempel på hur man konfigurerar Module Federation med Webpack 5. Vi skapar två enkla applikationer: en Host-applikation och en Remote-applikation. Remote-applikationen kommer att exponera en komponent, och Host-applikationen kommer att konsumera den.

1. Projektkonfiguration

Skapa två separata kataloger för dina applikationer: `host` och `remote`.

```bash mkdir host remote cd host npm init -y npm install webpack webpack-cli webpack-dev-server html-webpack-plugin --save-dev npm install react react-dom cd ../remote npm init -y npm install webpack webpack-cli webpack-dev-server html-webpack-plugin --save-dev npm install react react-dom ```

2. Konfiguration av Remote-applikationen

I `remote`-katalogen, skapa följande filer:

`src/index.js`: Startpunkt för applikationen.
`src/RemoteComponent.jsx`: Komponenten som kommer att exponeras.
`webpack.config.js`: Webpack-konfigurationsfil.

src/index.js:

```javascript import React from 'react'; import ReactDOM from 'react-dom/client'; import RemoteComponent from './RemoteComponent'; const App = () => (

Remote Application

); const root = ReactDOM.createRoot(document.getElementById('root')); root.render(); ```

src/RemoteComponent.jsx:

```javascript import React from 'react'; const RemoteComponent = () => (

This is a Remote Component!

Rendered from the Remote Application.

); export default RemoteComponent; ```

webpack.config.js:

```javascript const HtmlWebpackPlugin = require('html-webpack-plugin'); const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin'); const path = require('path'); module.exports = { entry: './src/index', mode: 'development', devServer: { port: 3001, static: { directory: path.join(__dirname, 'dist'), }, }, output: { publicPath: 'auto', }, module: { rules: [ { test: /\.(js|jsx)$/, exclude: /node_modules/, use: { loader: 'babel-loader', options: { presets: ['@babel/preset-react', '@babel/preset-env'], }, }, }, ], }, plugins: [ new ModuleFederationPlugin({ name: 'remote', filename: 'remoteEntry.js', exposes: { './RemoteComponent': './src/RemoteComponent', }, shared: { react: { singleton: true, eager: true }, 'react-dom': { singleton: true, eager: true }, }, }), new HtmlWebpackPlugin({ template: './public/index.html', }), ], resolve: { extensions: ['.js', '.jsx'], }, }; ```

Skapa `public/index.html` med grundläggande HTML-struktur. Det viktiga är `

3. Konfiguration av Host-applikationen

I `host`-katalogen, skapa följande filer:

`src/index.js`: Startpunkt för applikationen.
`webpack.config.js`: Webpack-konfigurationsfil.

src/index.js:

```javascript import React, { Suspense } from 'react'; import ReactDOM from 'react-dom/client'; const RemoteComponent = React.lazy(() => import('remote/RemoteComponent')); const App = () => (

Host Application

Loading Remote Component...

); const root = ReactDOM.createRoot(document.getElementById('root')); root.render(); ```

webpack.config.js:

```javascript const HtmlWebpackPlugin = require('html-webpack-plugin'); const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin'); const path = require('path'); module.exports = { entry: './src/index', mode: 'development', devServer: { port: 3000, static: { directory: path.join(__dirname, 'dist'), }, }, output: { publicPath: 'auto', }, module: { rules: [ { test: /\.(js|jsx)$/, exclude: /node_modules/, use: { loader: 'babel-loader', options: { presets: ['@babel/preset-react', '@babel/preset-env'], }, }, }, ], }, plugins: [ new ModuleFederationPlugin({ name: 'host', remotes: { remote: 'remote@http://localhost:3001/remoteEntry.js', }, shared: { react: { singleton: true, eager: true }, 'react-dom': { singleton: true, eager: true }, }, }), new HtmlWebpackPlugin({ template: './public/index.html', }), ], resolve: { extensions: ['.js', '.jsx'], }, }; ```

Skapa `public/index.html` med grundläggande HTML-struktur (liknande remote-appen). Det viktiga är `

4. Installera Babel

Installera Babel-beroenden i både `host`- och `remote`-katalogerna:

```bash npm install --save-dev @babel/core @babel/preset-env @babel/preset-react babel-loader ```

5. Kör applikationerna

Lägg till följande skript i `package.json` i både `host`- och `remote`-katalogerna:

```json "scripts": { "start": "webpack serve" } ```

Starta nu båda applikationerna:

```bash cd remote npm start cd ../host npm start ```

Öppna din webbläsare och navigera till `http://localhost:3000`. Du bör se Host-applikationen med Remote-komponenten renderad inuti den.

Förklaring av viktiga konfigurationsalternativ:

`name`: Ett unikt namn för applikationen.
`filename`: Namnet på filen som kommer att innehålla metadata om de exponerade modulerna (t.ex. `remoteEntry.js`).
`exposes`: En mappning av modulnamn till filsökvägar som specificerar vilka moduler som ska exponeras.
`remotes`: En mappning av remote-applikationsnamn till URL:er som specificerar var man hittar remoteEntry.js-filen för varje remote-applikation.
`shared`: En lista över moduler som ska delas mellan host- och remote-applikationerna. Alternativet `singleton: true` säkerställer att endast en instans av varje delad modul laddas. Alternativet `eager: true` säkerställer att den delade modulen laddas ivrigt (dvs. före några andra moduler).

Avancerade tekniker med Module Federation

Module Federation erbjuder många avancerade funktioner som kan hjälpa dig att bygga ännu mer sofistikerade mikro-frontend-arkitekturer.

Dynamiska Remotes

Istället för att hårdkoda URL:erna till remote-applikationer i Webpack-konfigurationen kan du ladda dem dynamiskt vid körtid. Detta gör att du enkelt kan uppdatera platsen för remote-applikationer utan att behöva bygga om host-applikationen.

Du kan till exempel lagra URL:erna till remote-applikationer i en konfigurationsfil eller en databas och ladda dem dynamiskt med JavaScript.

```javascript // I webpack.config.js remotes: { remote: `promise new Promise(resolve => { const urlParams = new URLSearchParams(window.location.search); const remoteUrl = urlParams.get('remote'); // Anta att remoteUrl är något i stil med 'http://localhost:3001/remoteEntry.js' const script = document.createElement('script'); script.src = remoteUrl; script.onload = () => { // nyckeln till module federation är att remote-appen är // tillgänglig via namnet i remote-konfigurationen resolve(window.remote); }; document.head.appendChild(script); })`, }, ```

Nu kan du ladda host-appen med en query-parameter `?remote=http://localhost:3001/remoteEntry.js`

Versionerade delade moduler

Module Federation kan automatiskt hantera versionering och deduplicering av delade moduler för att säkerställa att endast en kompatibel version av varje modul laddas. Detta är särskilt viktigt när man hanterar stora och komplexa applikationer med många beroenden.

Du kan specificera versionsintervallet för varje delad modul i Webpack-konfigurationen.

```javascript // I webpack.config.js shared: { react: { singleton: true, eager: true, requiredVersion: '^18.0.0' }, 'react-dom': { singleton: true, eager: true, requiredVersion: '^18.0.0' }, }, ```

Anpassade modulladdare

Module Federation låter dig definiera anpassade modulladdare som kan användas för att ladda moduler från olika källor eller i olika format. Detta kan vara användbart för att ladda moduler från en CDN eller från ett anpassat modulregister.

Dela state mellan mikro-frontends

En av utmaningarna med mikro-frontend-arkitekturer är att dela state mellan olika mikro-frontends. Det finns flera tillvägagångssätt du kan använda för att hantera denna utmaning:

URL-baserad state-hantering: Lagra state i URL:en och använd URL:en för att kommunicera mellan mikro-frontends. Detta är ett enkelt och rakt tillvägagångssätt, men det kan bli omständligt för komplext state.
Anpassade händelser (custom events): Använd anpassade händelser för att sända state-förändringar mellan mikro-frontends. Detta möjliggör lös koppling mellan mikro-frontends, men det kan vara svårt att hantera händelseprenumerationer.
Delat state-hanteringsbibliotek: Använd ett delat state-hanteringsbibliotek som Redux eller MobX för att hantera state för hela applikationen. Detta ger ett centraliserat och konsekvent sätt att hantera state, men det kan introducera ett beroende till ett specifikt state-hanteringsbibliotek.
Message Broker: Använd en meddelandekö som RabbitMQ eller Kafka för att underlätta kommunikation och delning av state mellan mikro-frontends. Detta är en mer komplex lösning, men den erbjuder en hög grad av flexibilitet och skalbarhet.

Bästa praxis för att implementera mikro-frontends med Module Federation

Här är några bästa praxis att tänka på när du implementerar mikro-frontends med Module Federation:

Definiera tydliga gränser för varje mikro-frontend: Varje mikro-frontend bör ansvara för en specifik affärsdomän eller funktion och ha väldefinierade gränssnitt.
Använd en konsekvent teknikstack: Även om Module Federation låter dig använda olika teknologier för olika mikro-frontends, är det generellt en bra idé att använda en konsekvent teknikstack för att minska komplexiteten och förbättra underhållbarheten.
Etablera tydliga kommunikationsprotokoll: Definiera tydliga kommunikationsprotokoll för hur mikro-frontends ska interagera med varandra.
Automatisera driftsättningsprocessen: Automatisera driftsättningsprocessen för att säkerställa att mikro-frontends kan driftsättas oberoende och pålitligt. Överväg att använda CI/CD-pipelines och verktyg för infrastruktur-som-kod.
Övervaka prestandan för dina mikro-frontends: Övervaka prestandan för dina mikro-frontends för att identifiera och åtgärda eventuella prestandaflaskhalsar. Använd verktyg som Google Analytics, New Relic eller Datadog.
Implementera robust felhantering: Implementera robust felhantering för att säkerställa att din applikation är motståndskraftig mot fel.
Omfamna en decentraliserad styrmodell: Ge team befogenhet att fatta beslut om sina egna mikro-frontends, samtidigt som övergripande konsistens och kvalitet bibehålls.

Verkliga exempel på Module Federation i praktiken

Även om specifika fallstudier ofta är konfidentiella, är här några generaliserade scenarier där Module Federation kan vara otroligt användbart:

E-handelsplattformar: Som nämnts tidigare kan stora e-handelsplattformar använda Module Federation för att bygga oberoende mikro-frontends för produktkatalogen, varukorgen, kassaprocessen och användarkontohanteringen. Detta gör att olika team kan arbeta på dessa funktioner oberoende och driftsätta dem utan att påverka andra delar av applikationen. En global plattform kan anpassa funktioner för olika regioner via fjärrmoduler.
Finansiella tjänsteapplikationer: Applikationer för finansiella tjänster har ofta komplexa användargränssnitt med många olika funktioner. Module Federation kan användas för att bygga oberoende mikro-frontends för olika kontotyper, handelsplattformar och rapportpaneler. Efterlevnadsfunktioner som är unika för vissa länder kan levereras via Module Federation.
Sjukvårdsportaler: Sjukvårdsportaler kan använda Module Federation för att bygga oberoende mikro-frontends för patienthantering, tidsbokning och tillgång till medicinska journaler. Olika moduler för olika försäkringsleverantörer eller regioner kan laddas dynamiskt.
Content Management Systems (CMS): Ett CMS kan använda Module Federation för att låta användare lägga till anpassad funktionalitet på sina webbplatser genom att ladda fjärrmoduler från tredjepartsutvecklare. Olika teman, plugins och widgets kan distribueras som oberoende mikro-frontends.
Learning Management Systems (LMS): Ett LMS kan erbjuda kurser som utvecklats oberoende och integreras i en enhetlig plattform via Module Federation. Uppdateringar av enskilda kurser kräver inte om-driftsättning av hela plattformen.

Slutsats

JavaScript Module Federation i Webpack 5 erbjuder ett kraftfullt och flexibelt sätt att bygga mikro-frontend-arkitekturer. Det låter dig dela kod mellan separat kompilerade JavaScript-applikationer vid körtid, vilket möjliggör oberoende driftsättningar, teknisk mångfald och förbättrad teamautonomi. Genom att följa de bästa praxis som beskrivs i denna guide kan du utnyttja Module Federation för att bygga skalbara, underhållbara och innovativa webbapplikationer.

Framtiden för frontend-utveckling lutar utan tvekan mot modulära och distribuerade arkitekturer. Module Federation utgör ett avgörande verktyg för att bygga dessa moderna system, vilket gör det möjligt för team att skapa komplexa applikationer med större hastighet, flexibilitet och motståndskraft. Allt eftersom tekniken mognar kan vi förvänta oss att se ännu fler innovativa användningsfall och bästa praxis dyka upp.