JavaScript Module Federation: En Omfattende Guide til Mikro-Frontend Arkitektur

I det stadig utviklende landskapet for web-utvikling, kan det å bygge store, komplekse applikasjoner raskt bli en overveldende oppgave. Tradisjonelle monolittiske arkitekturer fører ofte til tett koblede kodebaser, noe som hindrer skalerbarhet, vedlikeholdbarhet og uavhengige distribusjoner. Mikro-frontends tilbyr et overbevisende alternativ ved å bryte ned applikasjonen i mindre, uavhengig distribuerbare enheter. Blant de ulike mikro-frontend-teknikkene, fremstår JavaScript Module Federation som en kraftig og elegant løsning.

Hva er JavaScript Module Federation?

JavaScript Module Federation, introdusert av Webpack 5, lar JavaScript-applikasjoner dynamisk dele kode og avhengigheter under kjøring. I motsetning til tradisjonelle metoder for kodedeling som er avhengige av byggetidsavhengigheter, gjør Module Federation det mulig for applikasjoner å laste og kjøre kode fra andre applikasjoner, selv om de ble bygget med forskjellige teknologier eller versjoner av samme bibliotek. Dette skaper en virkelig distribuert og frikoblet arkitektur.

Tenk deg et scenario der du har flere team som jobber på forskjellige deler av en stor e-handelsnettside. Ett team kan være ansvarlig for produktkatalogen, et annet for handlekurven, og et tredje for brukerautentisering. Med Module Federation kan hvert team utvikle, bygge og distribuere sin mikro-frontend uavhengig, uten å måtte bekymre seg for konflikter eller avhengigheter med andre team. Hovedapplikasjonen ("verten") kan deretter dynamisk laste og gjengi disse mikro-frontendene ("fjern-enhetene") under kjøring, og skape en sømløs brukeropplevelse.

Nøkkelkonsepter i Module Federation

• Vert (Host): Hovedapplikasjonen som konsumerer og gjengir fjernmodulene.
• Fjern-enhet (Remote): En uavhengig applikasjon som eksponerer moduler for konsumering av andre applikasjoner.
• Delte Moduler (Shared Modules): Avhengigheter som deles mellom verten og fjern-enhetene. Dette unngår duplisering og sikrer konsistente versjoner på tvers av applikasjonen.
• Module Federation Plugin: Et Webpack-plugin som aktiverer Module Federation-funksjonalitet.

Fordeler med Module Federation

1. Uavhengige Distribusjoner

Hver mikro-frontend kan distribueres uavhengig uten å påvirke andre deler av applikasjonen. Dette gir raskere utgivelsessykluser, redusert risiko og økt smidighet. Et team i Berlin kan distribuere oppdateringer til produktkatalogen mens handlekurv-teamet i Tokyo fortsetter å jobbe uavhengig med sine funksjoner. Dette er en betydelig fordel for globalt distribuerte team.

2. Økt Skalerbarhet

Applikasjonen kan skaleres horisontalt ved å distribuere hver mikro-frontend på separate servere. Dette gir bedre ressursutnyttelse og forbedret ytelse. For eksempel kan autentiseringstjenesten, som ofte er en ytelsesflaskehals, skaleres uavhengig for å håndtere belastningstopper.

3. Forbedret Vedlikeholdbarhet

Mikro-frontends er mindre og mer håndterbare enn monolittiske applikasjoner, noe som gjør dem enklere å vedlikeholde og feilsøke. Hvert team har eierskap til sin egen kodebase, noe som lar dem fokusere på sitt spesifikke ekspertiseområde. Tenk deg et globalt team som spesialiserer seg på betalingsløsninger; de kan vedlikeholde den spesifikke mikro-frontenden uten å påvirke andre team.

4. Teknologiagnostisk

Mikro-frontends kan bygges med forskjellige teknologier eller rammeverk, noe som lar team velge de beste verktøyene for jobben. Én mikro-frontend kan være bygget med React, mens en annen bruker Vue.js. Denne fleksibiliteten er spesielt nyttig ved integrering av eldre applikasjoner eller når forskjellige team har ulike preferanser eller ekspertise.

5. Gjenbruk av Kode

Delte moduler kan gjenbrukes på tvers av flere mikro-frontends, noe som reduserer kodeduplisering og forbedrer konsistens. Dette er spesielt nyttig for felles komponenter, hjelpefunksjoner eller designsystemer. Tenk deg et globalt konsistent designsystem som deles på tvers av alle mikro-frontends, og som sikrer en enhetlig merkevareopplevelse.

Implementering av Module Federation: Et Praktisk Eksempel

La oss gå gjennom et forenklet eksempel på hvordan man implementerer Module Federation med Webpack 5. Vi vil lage to applikasjoner: en vert-applikasjon og en fjern-applikasjon. Fjern-applikasjonen vil eksponere en enkel komponent som vert-applikasjonen vil konsumere.

Steg 1: Sette opp Vert-applikasjonen

Opprett en ny mappe for vert-applikasjonen og initialiser et nytt npm-prosjekt:

            mkdir host-app
cd host-app
npm init -y
            

              
                Copy
              
            
          

Installer Webpack og dens avhengigheter:

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

              
                Copy
              
            
          

Opprett en `webpack.config.js`-fil i roten av vert-applikasjonen med følgende konfigurasjon:

            const HtmlWebpackPlugin = require('html-webpack-plugin');
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
const path = require('path');

module.exports = {
 mode: 'development',
 devtool: 'source-map',
 entry: './src/index.js',
 output: {
 path: path.resolve(__dirname, 'dist'),
 filename: 'bundle.js',
 publicPath: 'http://localhost:3000/', // Viktig for Module Federation
 },
 devServer: {
 port: 3000,
 hot: true,
 historyApiFallback: true,
 },
 module: {
 rules: [
 {
 test: /\.js$/,
 exclude: /node_modules/,
 use: {
 loader: 'babel-loader',
 options: {
 presets: ['@babel/preset-env', '@babel/preset-react'] // La til react-preset
 }
 }
 },
 {
 test: /\.css$/i,
 use: ["style-loader", "css-loader"],
 },
 ],
 },
 plugins: [
 new ModuleFederationPlugin({
 name: 'host',
 remotes: {
 remoteApp: 'remote@http://localhost:3001/remoteEntry.js', // Peker til fjern-enhetens entry-fil
 },
 shared: ['react', 'react-dom'], // Deler react
 }),
 new HtmlWebpackPlugin({
 template: './public/index.html',
 }),
 ],
};

            

              
                Copy
              
            
          

Denne konfigurasjonen definerer inngangspunktet, utdatamappen, utviklingsserverinnstillinger og Module Federation-pluginet. `remotes`-egenskapen spesifiserer plasseringen til fjern-applikasjonens `remoteEntry.js`-fil. `shared`-egenskapen definerer modulene som deles mellom vert- og fjern-applikasjonene. I dette eksempelet deler vi 'react' og 'react-dom'.

Opprett en `index.html`-fil i `public`-mappen:

            <!DOCTYPE html>
<html>
<head>
 <title>Host Application</title>
</head>
<body>
 <div id="root"></div>
<script src="/bundle.js"></script>
</body>
</html>
            

              
                Copy
              
            
          

Opprett en `src`-mappe og en `index.js`-fil inni den. Denne filen vil laste fjern-komponenten og gjengi den i vert-applikasjonen:

            import React from 'react';
import ReactDOM from 'react-dom/client';

import RemoteComponent from 'remoteApp/RemoteComponent';

const App = () => (
 <div>
 <h1>Vert-applikasjon</h1>
 <p>Dette er vert-applikasjonen som konsumerer en fjern-komponent.</p>
 <RemoteComponent />
 </div>
);

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(<App/>);

            

              
                Copy
              
            
          

Installer babel-loader og dens forhåndsinnstillinger

            npm install -D babel-loader @babel/core @babel/preset-env @babel/preset-react style-loader css-loader
            

              
                Copy
              
            
          

Steg 2: Sette opp Fjern-applikasjonen

Opprett en ny mappe for fjern-applikasjonen og initialiser et nytt npm-prosjekt:

            mkdir remote-app
cd remote-app
npm init -y
            

              
                Copy
              
            
          

Installer Webpack og dens avhengigheter:

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

              
                Copy
              
            
          

Opprett en `webpack.config.js`-fil i roten av fjern-applikasjonen med følgende konfigurasjon:

            const HtmlWebpackPlugin = require('html-webpack-plugin');
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
const path = require('path');

module.exports = {
 mode: 'development',
 devtool: 'source-map',
 entry: './src/index.js',
 output: {
 path: path.resolve(__dirname, 'dist'),
 filename: 'bundle.js',
 publicPath: 'http://localhost:3001/', // Viktig for Module Federation
 },
 devServer: {
 port: 3001,
 hot: true,
 historyApiFallback: true,
 },
 module: {
 rules: [
 {
 test: /\.js$/,
 exclude: /node_modules/,
 use: {
 loader: 'babel-loader',
 options: {
 presets: ['@babel/preset-env', '@babel/preset-react']
 }
 }
 },
 {
 test: /\.css$/i,
 use: ["style-loader", "css-loader"],
 },
 ],
 },
 plugins: [
 new ModuleFederationPlugin({
 name: 'remote',
 filename: 'remoteEntry.js',
 exposes: {
 './RemoteComponent': './src/RemoteComponent.js', // Eksponerer komponenten
 },
 shared: ['react', 'react-dom'], // Deler react
 }),
 new HtmlWebpackPlugin({
 template: './public/index.html',
 }),
 ],
};

            

              
                Copy
              
            
          

Denne konfigurasjonen ligner på vert-applikasjonen, men med noen viktige forskjeller. `name`-egenskapen er satt til `remote`, og `exposes`-egenskapen definerer modulene som eksponeres for andre applikasjoner. I dette tilfellet eksponerer vi `RemoteComponent`.

Opprett en `index.html`-fil i `public`-mappen:

            <!DOCTYPE html>
<html>
<head>
 <title>Remote Application</title>
</head>
<body>
 <div id="root"></div>
<script src="/bundle.js"></script>
</body>
</html>
            

              
                Copy
              
            
          

Opprett en `src`-mappe og en `RemoteComponent.js`-fil inni den. Denne filen vil inneholde komponenten som eksponeres for vert-applikasjonen:

            import React from 'react';

const RemoteComponent = () => (
 <div style={{ border: '2px solid red', padding: '10px', margin: '10px' }}>
 <h2>Fjern-komponent</h2>
 <p>Denne komponenten er lastet fra fjern-applikasjonen.</p>
 </div>
);

export default RemoteComponent;

            

              
                Copy
              
            
          

Opprett en `src`-mappe og en `index.js`-fil inni den. Denne filen vil gjengi `RemoteComponent` når fjern-applikasjonen kjøres uavhengig (valgfritt):

            import React from 'react';
import ReactDOM from 'react-dom/client';
import RemoteComponent from './RemoteComponent';

const App = () => (
 <div>
 <h1>Fjern-applikasjon</h1>
 <RemoteComponent />
 </div>
);

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(<App/>);

            

              
                Copy
              
            
          

Steg 3: Kjøre Applikasjonene

Legg til start-skript i begge `package.json`-filene:

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

              
                Copy
              
            
          

Start begge applikasjonene med `npm start`. Åpne nettleseren din og naviger til `http://localhost:3000`. Du skal se vert-applikasjonen som gjengir fjern-komponenten. Fjern-komponenten vil ha en rød ramme rundt seg, som indikerer at den er lastet fra fjern-applikasjonen.

Avanserte Konsepter og Vurderinger

1. Versjonering og Kompatibilitet

Når man deler avhengigheter mellom mikro-frontends, er det viktig å vurdere versjonering og kompatibilitet. Module Federation gir mekanismer for å spesifisere versjonsområder og løse konflikter. Verktøy som semantisk versjonering (semver) blir avgjørende for å håndtere avhengigheter og sikre kompatibilitet på tvers av forskjellige mikro-frontends. Manglende håndtering av versjonering kan føre til kjøretidsfeil eller uventet oppførsel, spesielt i komplekse systemer med mange mikro-frontends.

2. Autentisering og Autorisering

Implementering av autentisering og autorisering i en mikro-frontend-arkitektur krever nøye planlegging. Vanlige tilnærminger inkluderer bruk av en delt autentiseringstjeneste eller implementering av token-basert autentisering. Sikkerhet er avgjørende, og det er viktig å følge beste praksis for å beskytte sensitive data. For eksempel kan en e-handelsplattform ha en dedikert autentiserings-mikro-frontend som er ansvarlig for å verifisere brukerlegitimasjon før tilgang gis til andre mikro-frontends.

3. Kommunikasjon Mellom Mikro-Frontends

Mikro-frontends må ofte kommunisere med hverandre for å utveksle data eller utløse handlinger. Ulike kommunikasjonsmønstre kan brukes, som hendelser, delt tilstandshåndtering eller direkte API-kall. Valg av riktig kommunikasjonsmønster avhenger av de spesifikke kravene til applikasjonen. Verktøy som Redux eller Vuex kan brukes for delt tilstandshåndtering. Egendefinerte hendelser kan brukes for løs kobling og asynkron kommunikasjon. API-kall kan brukes for mer komplekse interaksjoner.

4. Ytelsesoptimalisering

Lasting av fjern-moduler kan påvirke ytelsen, spesielt hvis modulene er store eller nettverkstilkoblingen er treg. Optimalisering av modulstørrelsen, bruk av kodedeling (code splitting), og mellomlagring (caching) av fjern-moduler kan forbedre ytelsen. Lat lasting (lazy loading) av moduler kun når de trengs er en annen viktig optimaliseringsteknikk. Vurder også å bruke et Content Delivery Network (CDN) for å servere fjern-moduler fra geografisk nærmere lokasjoner til sluttbrukerne, og dermed redusere forsinkelse.

5. Testing av Mikro-Frontends

Testing av mikro-frontends krever en annen tilnærming enn testing av monolittiske applikasjoner. Hver mikro-frontend bør testes uavhengig, samt i integrasjon med andre mikro-frontends. Kontrakttesting kan brukes for å sikre at mikro-frontends er kompatible med hverandre. Enhetstester, integrasjonstester og ende-til-ende-tester er alle viktige for å sikre kvaliteten på en mikro-frontend-arkitektur.

6. Feilhåndtering og Overvåking

Implementering av robust feilhåndtering og overvåking er avgjørende for å identifisere og løse problemer i en mikro-frontend-arkitektur. Sentraliserte loggings- og overvåkingssystemer kan gi innsikt i applikasjonens helse og ytelse. Verktøy som Sentry eller New Relic kan brukes til å spore feil og ytelsesmålinger på tvers av forskjellige mikro-frontends. En godt designet feilhåndteringsstrategi kan forhindre kaskadefeil og sikre en robust brukeropplevelse.

Bruksområder for Module Federation

Module Federation er godt egnet for en rekke bruksområder, inkludert:

• Store E-handelsplattformer: Bryte ned nettstedet i mindre, uavhengig distribuerbare enheter for produktkatalog, handlekurv, brukerautentisering og kasse.
• Virksomhetsapplikasjoner: Bygge komplekse dashbord og portaler med forskjellige team ansvarlige for ulike seksjoner.
• Innholdsstyringssystemer (CMS): Tillate utviklere å lage og distribuere egendefinerte moduler eller plugins uavhengig.
• Mikrotjenestearkitekturer: Integrere front-end-applikasjoner med mikrotjeneste-backends.
• Progressive Web Apps (PWAer): Dynamisk lasting og oppdatering av funksjoner i en PWA.

For eksempel, vurder en multinasjonal bankapplikasjon. Med Module Federation kan kjernebankfunksjonene, investeringsplattformen og kundeserviceportalen utvikles og distribueres uavhengig. Dette lar spesialiserte team fokusere på spesifikke områder samtidig som det sikrer en enhetlig og konsistent brukeropplevelse på tvers av alle tjenester.

Alternativer til Module Federation

Selv om Module Federation tilbyr en overbevisende løsning for mikro-frontend-arkitekturer, er det ikke det eneste alternativet. Andre populære teknikker inkluderer:

• iFrames: En enkel, men ofte mindre fleksibel tilnærming som bygger inn en applikasjon i en annen.
• Web Components: Gjenbrukbare, egendefinerte HTML-elementer som kan brukes på tvers av forskjellige applikasjoner.
• Single-SPA: Et rammeverk for å bygge enkeltsideapplikasjoner med flere rammeverk.
• Byggetidsintegrasjon: Kombinere alle mikro-frontends til en enkelt applikasjon under byggeprosessen.

Hver teknikk har sine egne fordeler og ulemper, og det beste valget avhenger av de spesifikke kravene til applikasjonen. Module Federation skiller seg ut med sin kjøretidsfleksibilitet og evne til å dele kode dynamisk uten å kreve en full gjenoppbygging og redistribusjon av alle applikasjoner.

Konklusjon

JavaScript Module Federation er en kraftig teknikk for å bygge skalerbare, vedlikeholdbare og uavhengige mikro-frontend-arkitekturer. Den tilbyr en rekke fordeler, inkludert uavhengige distribusjoner, økt skalerbarhet, forbedret vedlikeholdbarhet, teknologiagnostisisme og gjenbruk av kode. Ved å forstå nøkkelkonseptene, implementere praktiske eksempler og vurdere avanserte konsepter, kan utviklere utnytte Module Federation til å bygge robuste og fleksible web-applikasjoner. Ettersom web-applikasjoner fortsetter å vokse i kompleksitet, gir Module Federation et verdifullt verktøy for å håndtere den kompleksiteten og gjøre det mulig for team å jobbe mer effektivt og virkningsfullt.

Omfavn kraften i desentralisert web-utvikling med JavaScript Module Federation og lås opp potensialet for å bygge virkelig modulære og skalerbare applikasjoner. Enten du bygger en e-handelsplattform, en virksomhetsapplikasjon eller et CMS, kan Module Federation hjelpe deg med å bryte ned applikasjonen i mindre, mer håndterbare enheter og levere en bedre brukeropplevelse.