En mikro-frontend-arkitektur opdeler en browserapplikation i uafhængigt byggede og udrullede dele, hvor hvert team har det fulde ansvar for sin egen del. Én kodebase, som alle teams skal stå i kø for at ændre, bliver til flere, som hvert team leverer via sin egen pipeline. Frontend-delen holder op med at være flaskehalsen bag en backend baseret på mikrotjenester.
Det er hele løftet. Det er ikke gratis. Du får uafhængig udrulning, teknologivalg pr. del og mindre bundter; til gengæld får du en fælles platform, der skal vedligeholdes, et designsystem, der skal håndhæves på tværs af teams, og koordineringsomkostninger, som kun få teams kan bære. Med færre end tre eller fire autonome teams koster overheaden normalt mere end den monolit, den erstatter.
Så er spørgsmålet, om mikro-frontends virker? Nej. Spørgsmålet er, om din organisation er nået til et punkt, hvor de kan betale sig. Dette indlæg gennemgår, hvad en mikro-frontend er, hvordan arkitekturen fungerer sammen med mikrotjenester, de faktiske gevinster og omkostninger ved levering, hvad platformen koster at drive, samt et tjek af parathed i tre trin, som du kan bruge på din egen løsning, før du beslutter dig.
En micro frontend består af flere små, selvstændige og modulære komponenter. Modulerne er selvstændige enheder, som kan genbruges på andre sider. Du kan skrive disse komponenter i et hvilket som helst programmeringssprog: JavaScript og JavaScript-frameworks er de mest populære valg, men alt, hvad der kan kompileres og pakkes til et JavaScript-bundle, kan importeres og sammensættes af resten af frontenden.
Tænk på et indkøbscenter. Ét tag, én indgang, én parkeringsplads, fælles skiltning, og bag hver butiksfacade indretter et forskelligt team sit eget område efter sin egen tidsplan. For kunderne fremstår det som ét samlet sted, mens butikkerne drives af dem, der har bedst forstand på den enkelte branche.
I en micro frontend-arkitektur er det præcis det samme princip. Du opdeler den monolitiske applikation i mindre stykker og koder, tester og udruller hvert fragment separat, så tværfaglige teams kan udvikle hver komponent – fra database til brugerflade – uafhængigt af hinanden. Det, der skjuler overgangene, er skallen (the shell) og det fælles designsystem: Skallen samler alle delene til én side med én navigation og én session, og designsystemet sikrer, at de har de samme komponenter og det samme visuelle udtryk.
Mønsteret blev navngivet og katalogiseret på micro-frontends.org, og Martin Fowlers team udgav den kanoniske beskrivelse af micro frontend-mønsteret, inklusive de integrationsstile, vi kommer ind på længere nede.
Her er et par kendte virksomheder, der bruger micro frontends:
Betragt denne liste som bevis på, at mønsteret kan skaleres, ikke som en grund til at tage det i brug. Hver virksomhed på listen driver dusinvis af frontend-teams. Det er den forudsætning, arkitekturen er et svar på.
Målet med en micro frontend er at give dig det, som microservices gav backenden, uden de ulemper, der følger med en stor frontend-monolit.
For at forstå, hvorfor det virker, må vi være præcise omkring to ting: hvad microservices rent faktisk ændrede på serversiden, og hvad der stædigt forblev uændret på clientsiden. Vi så begge sider af den grænse genopbygge Eurofounds frontend- og backend-integration, hvor en modulær backend stadig skulle møde en samlet frontend.
Microservice-arkitektur er et designmønster inden for backend-udvikling. Hvor en monolitisk arkitektur leveres som én enhed, består microservices af flere uafhængigt deployerbare komponenter, adskilt af forretningsdomæner og forbundet via API'er.
Hvad det giver en virksomhed, er mere begrænset, end den sædvanlige liste af tillægsord antyder, og det er værd at sige direkte:
Disse fire punkter er præcis de egenskaber, en frontend-monolit ikke har, uanset hvor moderne backenden bag den er. Vores guide til softwarearkitektur beskriver, hvor balancen ligger ved forskellige teamstørrelser.
En frontend-monolit er klientsiden af en webapplikation, der er bygget ud fra en enkelt kodebase. Mange produkter kører stadig sådan, også produkter, hvis backend er fuldt dekomponeret. Serversiden er modulær; frontenden forbliver en helhed.
For et eller to teams er det den rette struktur. Sandheden er, at det som regel er den rette struktur i længere tid, end folk forventer. Symptomerne viser sig, efterhånden som antallet af teams, der arbejder i kodebasen, vokser, og de er specifikke nok til at holde øje med:
En frontend-monolit begrænser med andre ord den uafhængige levering, som var grunden til, at I valgte mikrotjenester. Det er det hul, micro frontends lukker. Og det er værd at være direkte omkring karakteren af det hul: Det er organisatorisk. Hvis forsinkelsen ligger i review-kulturen eller i et change board frem for i kodebasen, vil en opsplitning af kodebasen ikke løse problemet.
Uafhængig deployment hjælper kun, hvis leveringsprocessen bag den er disciplineret, hvilket er der, hvor de bedste agile praksisser retfærdiggør deres plads.
Med en micro frontend kan virksomheder:
Dette er velegnet til teams, der allerede arbejder med uafhængig levering på backenden. Gevinsterne er reelle, men hver af dem har en pris, som gennemgås i næste afsnit.
Listen over fordele ved denne arkitektur er lang. I praksis kan de koges ned til fire gevinster, hver med sin bagvedliggende mekanisme og betingelse.
Omkostningerne er de samme fire egenskaber set fra den anden side. Ingen af dem er en grund til at undgå arkitekturen. Alle kræver en ansvarlig, før du går i gang.
De to arkitekturer løser forskellige problemer. Her er et hurtigt overblik over afvejningerne – læs det som "hvilken begrænsning arbejder du under?" frem for "hvad er bedst?".
| Dimension | Monolitisk frontend | Mikro-frontend |
|---|---|---|
| Kodebase | Ét fælles repository, som alle ændrer i | Flere uafhængigt ejede sektioner |
| Udrulning (Deployment) | Én fælles pipeline / release train | Pipeline pr. sektion, udrul efter behov |
| Teamstørrelse | Et eller to teams | Tre, fire eller flere autonome teams |
| Release-kadence | Styret af den langsomste ændring i batchen | Hver sektion leveres, når den er klar |
| Skadesradius (Blast radius) | En fejltilstand kan lægge hele frontenden ned | Begrænset til én enkelt sektion |
| Teknologi | Fælles framework og versioner; en opgradering er et projekt for hele produktet | Valg pr. sektion; en opgradering afprøves først på én sektion |
| Bundle-størrelse | Én samlet pakke, ingen duplikering | Kun den kode, som en side har brug for — men risiko for duplikerede framework-kopier |
| Test | Enklere end-to-end: én enhed at teste | Sektioner testes i isolation; det samlede produkt kræver sin egen e2e-testsuite |
| Løbende platformskomkostninger | Ingen ud over selve applikationen | Skal (Shell) + komposition + designsystem + e2e-testsuite (≈ én ingeniør plus en ansvarlig for designsystemet) |
| Bedst når | Release-flaskehalse ikke er din primære forhindring | Flere autonome teams står i kø for at udrulle på den samme kodebase |
Den forretningsmæssige case er en afvejning mellem koordineringsomkostninger og leveringshastighed, og den giver kun mening ved en vis skala. Tallene herunder er vejledende snarere end universelle. Selve balancen i afvejningen er vigtigere end de konkrete tal.
Micro frontend-arkitektur har klare fordele, men det er ikke en løsning, der passer til alt. Ikke alle webapplikationer egner sig til denne stil, og de afgørende faktorer er i lige så høj grad organisatoriske som tekniske.
Før vi tager micro frontends i brug, sender vi kandidaten gennem tre porte. Hvis bare én af dem fejler, er monolitten stadig det bedste svar, og den pågældende port er det område, der skal arbejdes på først.
To understøttende betingelser er også vigtige. Separate teknologistakke til forskellige moduler bør være et reelt krav frem for en præference, og budgettet skal kunne dække de faste platformomkostninger, der er beskrevet ovenfor.
Hvis du er i tvivl om, hvorvidt micro frontends passer til dit projekt, så gennemgå de tre porte med en person, der har prøvet at gennemføre migreringen før. I sidste ende afhænger det af de specifikke forhold i din forretningsplan og ikke af arkitekturens abstrakte fordele.
At opdele frontenden er den nemme del. Det, der afgør, om resultatet hænger sammen, ligger i fire ansvarsområder, som ingen enkelt del ejer, og som hver især kræver en beslutning før den første migrering frem for efter.
Hjælpekomponenter, der administrerer tilstand eller kommunikerer med applikationsmiljøet i stedet for at rendere noget, kan indlæses efter behov ligesom enhver anden del. De indeholder normalt ingen brugerflade, hvilket gør dem nemme at overse, når du skal beslutte, hvem der ejer hvad.
Du kan integrere micro frontends på to måder: ved build-time eller ved run-time.
Containeren installerer hver slice som et bibliotek, ligesom når du installerer en pakke fra npm, Node.js-pakkeregistret. Det er sådan, det meste kode skrives i dag, og det er den simpleste løsning, der virker.
Ulemperne er årsagen til, at de fleste teams bevæger sig videre. Flere versioner af delte biblioteker skal holdes synkroniserede, hvilket ofte fører til build-problemer, hvis de ikke er det. Det er svært at kombinere forskellige teknologier. Den endelige pakke indeholder alle afhængigheder, så den bliver stor. Og da enhver ændring af en afhængighed kræver genopbygning og genudrulning af containeren, forbliver containeren og alle dens slices tæt koblede. Det er netop denne kobling, arkitekturen er skabt for at fjerne.
Run-time-integration sammensætter siden af uafhængigt udrullede slices, mens den serveres eller efter den er indlæst, så en slice kan udgives uden at genopbygge containeren. Der findes tre typer komposition:
@module-federation/nextjs-mf pluginnet har kun nogensinde understøttet den ældre Pages Router, aldrig den nuværende standard App Router, og vedligeholderne har markeret det til udfasning omkring slutningen af 2026. Til App Router-projekter er Vercels officielle @vercel/microfrontends pakke – bygget på en Multi-Zones-model frem for run-time chunk-stitching – nu den understøttede vej. single-spa er fortsat det primære alternativ, hvor slices er bygget med forskellige frameworks.En micro frontend er en del af en webapplikations brugerflade, som bygges og implementeres uafhængigt af det team, der ejer den. I stedet for én samlet frontend-kodebase, som alle ændrer i, samles siden af flere uafhængige dele under build-processen eller direkte i browseren. Hvert team kan udgive deres ændringer uden at vente på de andre.
Vælg monolitten, medmindre flaskehalsen i jeres proces reelt er ventetid på releases. En samlet frontend-kodebase er enklere at bygge, teste og gennemskue, og det er det rigtige valg for et eller to teams. Micro frontends bliver først rentable, når flere selvstændige teams står i kø for at deploye til den samme kodebase, og det er køen – ikke koden – der bremser jer.
Udover selve team-omkostningerne skal du budgettere med faste platformomkostninger: shell-applikationen, kompositionslaget, et delt designsystem og en end-to-end testsuite. I de projekter, vi ser, svarer det til cirka én fuldtidsingeniør plus en ansvarlig for designsystemet, og disse omkostninger fortsætter efter lancering. Gevinsten, der opvejer dette, er hurtigere gennemløbstid, ikke besparelser på antallet af medarbejdere.
Tre eller fire selvstændige frontend-teams er normalt grænsen, og autonomi betyder mere end selve antallet. Hvis alle releases stadig skal godkendes af én leder eller et change board, fjerner man en flaskehals, der aldrig var den begrænsende faktor. Hvis ét team indfører micro frontends, får man de operationelle omkostninger ved et distribueret system uden at få nogen af de organisatoriske fordele.
Tre fejl går igen. At sende en kopi af frameworket med hver del, så siden ender med at være langsommere end den monolit, den erstattede. At lade designsystemet være uden ejer, så brugerfladen visuelt glider fra hinanden mellem de forskellige dele. Og at lade versioner skride mellem uafhængigt deployede dele, hvilket først opdages i produktion. Alle tre er ledelsesmæssige svigt snarere end tekniske.
Det kan gå begge veje. Ved at opdele applikationen downloader browseren kun den kode, som den aktuelle side har brug for, hvilket er en fordel. Duplikerede afhængigheder på tværs af dele trækker i den modsatte retning og kan gøre den samlede datamængde større end før. Hvilken effekt der vinder, afhænger af, om delte afhængigheder styres bevidst, så mål hellere hastigheden for hver release frem for at tage det for givet.
Ja, og det er den sikreste vej. Placer en shell foran den eksisterende monolit, udskil ét vertikalt område med klare grænser, og giv et team ansvaret for det fra ende til anden. Hver efterfølgende del følger samme proces. Forvent at migreringen tager kvartaler frem for sprints, og behold muligheden for at stoppe undervejs.
Micro frontends giver frontend-udviklingen det, som microservices gav backend-udviklingen: uafhængig levering ved at bytte koordineringsomkostninger ud med leveringshastighed. Den handel giver kun mening i stor skala: platformen medfører faste omkostninger, og fejltyperne er organisatoriske snarere end tekniske. Så kør de tre tjek først: antallet af teams og deres autonomi, domæneadskillelse og modenhed i deployment. Hvis et af punkterne fejler, er det vigtigere at få det løst, og så er monolitten stadig det bedste valg for nu.
Vi har bygget, vedligeholdt og migreret både micro frontends og monolitter, og vi hjælper gerne din virksomhed gennem de tre tjek – også hvis konklusionen er, at I bør blive, hvor I er. Kontakt os så tager vi et kig på det.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
Din daglige webudvikler, der kan lide at gemme sig i backend. Javascript og Ruby er min marmelade. Jeg fumler stadig med Docker, og mine bygninger går i stykker ret ofte.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
