16. august 2025Norsk

Frigjør kraften i mikro-frontender med JavaScript Module Federation i Webpack 5. Lær hvordan du bygger skalerbare, vedlikeholdbare og uavhengige webapplikasjoner.

JavaScript Module Federation med Webpack 5: En Omfattende Guide til Mikro-frontender

I det stadig utviklende landskapet for webutvikling, kan det være en formidabel oppgave å bygge store og komplekse applikasjoner. Tradisjonelle monolittiske arkitekturer fører ofte til økt utviklingstid, flaskehalser ved utrulling og utfordringer med å opprettholde kodekvalitet. Mikro-frontender har dukket opp som et kraftig arkitekturmønster for å møte disse utfordringene, og lar team bygge og rulle ut uavhengige deler av en større webapplikasjon. En av de mest lovende teknologiene for å implementere mikro-frontender er JavaScript Module Federation, introdusert i Webpack 5.

Hva er Mikro-frontender?

Mikro-frontender er en arkitektonisk stil der en frontend-applikasjon deles opp i mindre, uavhengige enheter, som kan utvikles, testes og rulles ut autonomt av forskjellige team. Hver mikro-frontend er ansvarlig for et spesifikt forretningsdomene eller en funksjon, og de settes sammen under kjøring for å danne det komplette brukergrensesnittet.

Tenk på det som et selskap: i stedet for å ha ett gigantisk utviklingsteam, har du flere mindre team som fokuserer på spesifikke områder. Hvert team kan jobbe uavhengig, noe som gir raskere utviklingssykluser og enklere vedlikehold. Se for deg en stor e-handelsplattform som Amazon; forskjellige team kan håndtere produktkatalogen, handlekurven, utsjekkingsprosessen og brukerkontoadministrasjon. Disse kunne alle vært uavhengige mikro-frontender.

Fordeler med Mikro-frontender:

Uavhengige Utrullinger: Team kan rulle ut sine mikro-frontender uavhengig, uten å påvirke andre deler av applikasjonen. Dette reduserer risikoen ved utrulling og gir raskere utgivelsessykluser.
Teknologiuavhengig: Forskjellige mikro-frontender kan bygges med forskjellige teknologier eller rammeverk (f.eks. React, Angular, Vue.js). Dette lar team velge den beste teknologien for sine spesifikke behov og gradvis ta i bruk nye teknologier uten å måtte skrive om hele applikasjonen. Tenk deg ett team som bruker React for produktkatalogen, et annet som bruker Vue.js for markedsføringssider, og et tredje som bruker Angular for utsjekkingsprosessen.
Forbedret Teamautonomi: Team har fullt eierskap til sine mikro-frontender, noe som fører til økt autonomi, raskere beslutningstaking og forbedret utviklerproduktivitet.
Økt Skalerbarhet: Mikro-frontender lar deg skalere applikasjonen horisontalt ved å rulle ut individuelle mikro-frontender på forskjellige servere.
Gjenbruk av Kode: Delte komponenter og biblioteker kan enkelt deles mellom mikro-frontender.
Lettere å Vedlikeholde: Mindre kodebaser er generelt lettere å forstå, vedlikeholde og feilsøke.

Utfordringer med Mikro-frontender:

Økt Kompleksitet: Å administrere flere mikro-frontender kan legge til kompleksitet i den overordnede arkitekturen, spesielt med tanke på kommunikasjon, tilstandshåndtering og utrulling.
Ytelses-overhead: Lasting av flere mikro-frontender kan introdusere ytelses-overhead, spesielt hvis de ikke er optimalisert riktig.
Tverrgående Bekymringer: Håndtering av tverrgående bekymringer som autentisering, autorisasjon og temaer kan være utfordrende i en mikro-frontend-arkitektur.
Driftsmessig Overhead: Krever modne DevOps-praksiser og infrastruktur for å håndtere utrulling og overvåking av flere mikro-frontender.

Hva er JavaScript Module Federation?

JavaScript Module Federation er en funksjon i Webpack 5 som lar deg dele kode mellom separat kompilerte JavaScript-applikasjoner under kjøring. Det gjør det mulig å eksponere deler av applikasjonen din som "moduler" som kan konsumeres av andre applikasjoner, uten å måtte publisere til et sentralt register som npm.

Tenk på Module Federation som en måte å skape et føderert økosystem av applikasjoner, der hver applikasjon kan bidra med sin egen funksjonalitet og konsumere funksjonalitet fra andre applikasjoner. Dette eliminerer behovet for avhengigheter ved byggetid og muliggjør virkelig uavhengige utrullinger.

For eksempel kan et designsystem-team eksponere UI-komponenter som moduler, og forskjellige applikasjonsteam kan konsumere disse komponentene direkte fra designsystem-applikasjonen, uten å måtte installere dem som npm-pakker. Når designsystem-teamet oppdaterer komponentene, reflekteres endringene automatisk i alle konsumerende applikasjoner.

Nøkkelkonsepter i Module Federation:

Host (Vert): Hovedapplikasjonen som konsumerer eksterne moduler.
Remote (Fjern): En applikasjon som eksponerer moduler for å bli konsumert av andre applikasjoner.
Shared Modules (Delte Moduler): Moduler som deles mellom vert- og fjernapplikasjoner (f.eks. React, Lodash). Module Federation kan automatisk håndtere versjonering og deduplisering av delte moduler for å sikre at bare én versjon av hver modul lastes.
Exposed Modules (Eksponerte Moduler): Spesifikke moduler fra en fjernapplikasjon som gjøres tilgjengelige for konsumering av andre applikasjoner.
RemoteEntry.js: En fil generert av Webpack som inneholder metadata om de eksponerte modulene til en fjernapplikasjon. Vertsapplikasjonen bruker denne filen til å oppdage og laste de eksterne modulene.

Sette opp Module Federation med Webpack 5: En Praktisk Guide

La oss gå gjennom et praktisk eksempel på å sette opp Module Federation med Webpack 5. Vi vil lage to enkle applikasjoner: en Host-applikasjon (vert) og en Remote-applikasjon (fjern). Remote-applikasjonen vil eksponere en komponent, og Host-applikasjonen vil konsumere den.

1. Prosjektoppsett

Opprett to separate mapper for applikasjonene dine: `host` og `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. Konfigurasjon av Remote-applikasjonen

I `remote`-mappen, opprett følgende filer:

`src/index.js`: Inngangspunkt for applikasjonen.
`src/RemoteComponent.jsx`: Komponentet som skal eksponeres.
`webpack.config.js`: Webpack-konfigurasjonsfil.

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'], }, }; ```

Opprett `public/index.html` med grunnleggende HTML-struktur. Det viktige er `

3. Konfigurasjon av Host-applikasjonen

I `host`-mappen, opprett følgende filer:

`src/index.js`: Inngangspunkt for applikasjonen.
`webpack.config.js`: Webpack-konfigurasjonsfil.

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'], }, }; ```

Opprett `public/index.html` med grunnleggende HTML-struktur (lignende som remote-appen). Det viktige er `

4. Installer Babel

I både `host`- og `remote`-mappene, installer Babel-avhengigheter:

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

5. Kjør Applikasjonene

I både `host`- og `remote`-mappene, legg til følgende skript i `package.json`:

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

Start nå begge applikasjonene:

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

Åpne nettleseren din og naviger til `http://localhost:3000`. Du bør se Host-applikasjonen med Remote-komponentet rendret inne i den.

Forklaring av Viktige Konfigurasjonsalternativer:

`name`: Et unikt navn for applikasjonen.
`filename`: Navnet på filen som vil inneholde metadata om de eksponerte modulene (f.eks. `remoteEntry.js`).
`exposes`: Et kart over modulnavn til filstier, som spesifiserer hvilke moduler som skal eksponeres.
`remotes`: Et kart over navn på fjernapplikasjoner til URL-er, som spesifiserer hvor man finner remoteEntry.js-filen for hver fjernapplikasjon.
`shared`: En liste over moduler som skal deles mellom vert- og fjernapplikasjoner. Alternativet `singleton: true` sikrer at bare én instans av hver delte modul lastes. Alternativet `eager: true` sikrer at den delte modulen lastes ivrig (dvs. før noen andre moduler).

Avanserte Teknikker i Module Federation

Module Federation tilbyr mange avanserte funksjoner som kan hjelpe deg med å bygge enda mer sofistikerte mikro-frontend-arkitekturer.

Dynamiske Remotes

I stedet for å hardkode URL-ene til fjernapplikasjoner i Webpack-konfigurasjonen, kan du laste dem dynamisk under kjøring. Dette lar deg enkelt oppdatere plasseringen til fjernapplikasjoner uten å måtte bygge vertsapplikasjonen på nytt.

For eksempel kan du lagre URL-ene til fjernapplikasjoner i en konfigurasjonsfil eller en database og laste dem dynamisk ved hjelp av JavaScript.

```javascript // In webpack.config.js remotes: { remote: `promise new Promise(resolve => { const urlParams = new URLSearchParams(window.location.search); const remoteUrl = urlParams.get('remote'); // Anta at remoteUrl er noe som 'http://localhost:3001/remoteEntry.js' const script = document.createElement('script'); script.src = remoteUrl; script.onload = () => { // nøkkelen i module federation er at fjernappen er // tilgjengelig via navnet i fjernkonfigurasjonen resolve(window.remote); }; document.head.appendChild(script); })`, }, ```

Nå kan du laste vertappen med en query-parameter `?remote=http://localhost:3001/remoteEntry.js`

Versjonerte Delte Moduler

Module Federation kan automatisk håndtere versjonering og deduplisering av delte moduler for å sikre at bare én kompatibel versjon av hver modul lastes. Dette er spesielt viktig når man håndterer store og komplekse applikasjoner med mange avhengigheter.

Du kan spesifisere versjonsområdet for hver delte modul i Webpack-konfigurasjonen.

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

Egendefinerte Modullastere

Module Federation lar deg definere egendefinerte modullastere som kan brukes til å laste moduler fra forskjellige kilder eller i forskjellige formater. Dette kan være nyttig for å laste moduler fra en CDN eller fra et egendefinert modulregister.

Dele Tilstand mellom Mikro-frontender

En av utfordringene med mikro-frontend-arkitekturer er å dele tilstand mellom forskjellige mikro-frontender. Det er flere tilnærminger du kan ta for å løse denne utfordringen:

URL-basert tilstandshåndtering: Lagre tilstanden i URL-en og bruk URL-en til å kommunisere mellom mikro-frontender. Dette er en enkel og rett frem tilnærming, men den kan bli tungvint for kompleks tilstand.
Egendefinerte hendelser: Bruk egendefinerte hendelser (custom events) for å kringkaste tilstandsendringer mellom mikro-frontender. Dette gir løs kobling mellom mikro-frontender, men det kan være vanskelig å håndtere hendelsesabonnementer.
Delt tilstandshåndteringsbibliotek: Bruk et delt tilstandshåndteringsbibliotek som Redux eller MobX for å håndtere tilstanden til hele applikasjonen. Dette gir en sentralisert og konsekvent måte å håndtere tilstand på, men det kan introdusere en avhengighet til et spesifikt tilstandshåndteringsbibliotek.
Meldingsmegler: Bruk en meldingsmegler som RabbitMQ eller Kafka for å fasilitere kommunikasjon og tilstandsdeling mellom mikro-frontender. Dette er en mer kompleks løsning, men den tilbyr en høy grad av fleksibilitet og skalerbarhet.

Beste Praksis for Implementering av Mikro-frontender med Module Federation

Her er noen beste praksiser å ha i bakhodet når du implementerer mikro-frontender med Module Federation:

Definer klare grenser for hver mikro-frontend: Hver mikro-frontend bør være ansvarlig for et spesifikt forretningsdomene eller en funksjon og ha veldefinerte grensesnitt.
Bruk en konsistent teknologistabel: Selv om Module Federation lar deg bruke forskjellige teknologier for forskjellige mikro-frontender, er det generelt en god idé å bruke en konsistent teknologistabel for å redusere kompleksitet og forbedre vedlikeholdbarheten.
Etabler klare kommunikasjonsprotokoller: Definer klare kommunikasjonsprotokoller for hvordan mikro-frontender skal interagere med hverandre.
Automatiser utrullingsprosessen: Automatiser utrullingsprosessen for å sikre at mikro-frontender kan rulles ut uavhengig og pålitelig. Vurder å bruke CI/CD-pipelines og verktøy for infrastruktur-som-kode.
Overvåk ytelsen til dine mikro-frontender: Overvåk ytelsen til dine mikro-frontender for å identifisere og adressere eventuelle ytelsesflaskehalser. Bruk verktøy som Google Analytics, New Relic eller Datadog.
Implementer robust feilhåndtering: Implementer robust feilhåndtering for å sikre at applikasjonen din er motstandsdyktig mot feil.
Omfavn en desentralisert styringsmodell: Gi teamene myndighet til å ta beslutninger om sine egne mikro-frontender, samtidig som man opprettholder overordnet konsistens og kvalitet.

Eksempler fra den Virkelige Verden på Module Federation i Praksis

Selv om spesifikke casestudier ofte er konfidensielle, er her noen generaliserte scenarioer der Module Federation kan være utrolig nyttig:

E-handelsplattformer: Som nevnt tidligere, kan store e-handelsplattformer bruke Module Federation til å bygge uavhengige mikro-frontender for produktkatalogen, handlekurven, utsjekkingsprosessen og brukerkontoadministrasjon. Dette lar forskjellige team jobbe med disse funksjonene uavhengig og rulle dem ut uten å påvirke andre deler av applikasjonen. En global plattform kan tilpasse funksjoner for forskjellige regioner via eksterne moduler.
Finansielle Tjenesteapplikasjoner: Finansielle tjenesteapplikasjoner har ofte komplekse brukergrensesnitt med mange forskjellige funksjoner. Module Federation kan brukes til å bygge uavhengige mikro-frontender for forskjellige kontotyper, handelsplattformer og rapporteringsdashbord. Samsvarsfunksjoner unike for visse land kan leveres via Module Federation.
Helseportaler: Helseportaler kan bruke Module Federation til å bygge uavhengige mikro-frontender for pasientadministrasjon, timebestilling og tilgang til medisinske journaler. Forskjellige moduler for forskjellige forsikringsleverandører eller regioner kan lastes dynamisk.
Innholdsstyringssystemer (CMS): Et CMS kan bruke Module Federation for å la brukere legge til egendefinert funksjonalitet på sine nettsteder ved å laste eksterne moduler fra tredjepartsutviklere. Forskjellige temaer, plugins og widgets kan distribueres som uavhengige mikro-frontender.
Læringsstyringssystemer (LMS): Et LMS kan tilby kurs utviklet uavhengig og integrert i en enhetlig plattform via Module Federation. Oppdateringer til individuelle kurs krever ikke plattformomfattende nyutrullinger.

Konklusjon

JavaScript Module Federation i Webpack 5 gir en kraftig og fleksibel måte å bygge mikro-frontend-arkitekturer på. Det lar deg dele kode mellom separat kompilerte JavaScript-applikasjoner under kjøring, noe som muliggjør uavhengige utrullinger, teknologisk mangfold og forbedret teamautonomi. Ved å følge beste praksis beskrevet i denne guiden, kan du utnytte Module Federation til å bygge skalerbare, vedlikeholdbare og innovative webapplikasjoner.

Fremtiden for frontend-utvikling lener seg utvilsomt mot modulære og distribuerte arkitekturer. Module Federation gir et avgjørende verktøy for å bygge disse moderne systemene, og gjør det mulig for team å lage komplekse applikasjoner med større hastighet, fleksibilitet og robusthet. Etter hvert som teknologien modnes, kan vi forvente å se enda flere innovative bruksområder og beste praksiser dukke opp.