Written by:
Last Published:
6 augusti 2026
•
En mikrofrontend-arkitektur delar upp en webbläsarapplikation i oberoende byggda och distribuerade delar, där varje del ägs från början till slut av ett enskilt team. En kodbas som alla team köar för att ändra blir till flera, där varje team levererar via sin egen pipeline. Frontend slutar vara flaskhalsen bakom en backend baserad på mikrotjänster.
Det är hela löftet. Det är inte gratis. Du vinner oberoende driftsättning, teknikval per del och mindre paket; du tar på dig en delad plattform att underhålla, ett designsystem att kontrollera mellan teamen och en koordineringskostnad som bara ett fåtal team kan hantera. Med färre än tre eller fyra autonoma team kostar omkostnaderna oftast mer än den monolit de ersätter.
Så är frågan om mikrofrontends fungerar? Nej. Frågan är om din organisation har nått den punkt där de lönar sig. Det här inlägget går igenom vad en mikrofrontend är, hur arkitekturen förhåller sig till mikrotjänster, vinsterna och kostnaderna så som de faktiskt påverkar leveransen, vad plattformen kostar att driva, samt en kontroll i tre steg som du kan använda för att utvärdera din egen verksamhet innan du fattar ett beslut.
En mikro-frontend består av flera små, autonoma och modulära komponenter. Modulerna är fristående och kan återanvändas på andra sidor. Du kan skriva dessa komponenter i vilket programmeringsspråk som helst: JavaScript och JavaScript-ramverk är de populäraste valen, men allt som kan kompileras och paketeras till ett JavaScript-paket kan importeras och sättas samman av resten av frontenden.
Tänk dig ett köpcentrum. Ett tak, en entré, en parkeringsplats, gemensam skyltning, och bakom varje butiksfasad finns ett team som inreder sin egen yta enligt sitt eget schema. Kunderna upplever en enhetlig plats, medan butikerna drivs av de som är experter på just sin verksamhet.
I en mikro-frontend-arkitektur är det precis så det fungerar. Du bryter ner den monolitiska applikationen i mindre delar och kodar, testar och driftsätter varje fragment separat, vilket gör att tvärfunktionella team kan utveckla varje komponent – från databas till användargränssnitt – oberoende av varandra. Det som döljer skarvarna är ett skal och ett gemensamt designsystem: skalet renderar varje del till en sida med en gemensam navigering och session, och designsystemet ser till att de har samma komponenter och stil.
Mönstret namngavs och katalogiserades på micro-frontends.org, och Martin Fowlers team publicerade den kanoniska beskrivningen av mikro-frontend-mönstret, inklusive de integrationsstilar vi går in på längre ner.
Här är några välkända företag som använder mikro-frontends:
Se den listan som bevis på att mönstret är skalbart, inte som ett skäl att använda det. Varje företag på listan driver dussintals frontend-team. Det är den förutsättningen som arkitekturen är ett svar på.
Målet med en mikro-frontend är att ge dig det som mikrotjänster gav backend-utvecklingen, utan de nackdelar som följer med en stor frontend-monolit.
För att förstå varför det fungerar måste vi vara tydliga med två saker: vad mikrotjänster faktiskt förändrade på serversidan och vad som envist förblev oförändrat på klientsidan. Vi såg båda sidor av den gränsen bygga om Eurofounds integration av frontend och backend, där en modulär backend fortfarande behövde möta en enhetlig frontend.
Mikrotjänstarkitektur är ett designmönster inom backend-utveckling. Där en monolitisk arkitektur levereras som en enhet, består mikrotjänster av flera oberoende distribuerbara komponenter, uppdelade efter affärsområden och sammankopplade via API:er.
Vad detta ger en verksamhet är mer begränsat än vad den vanliga listan av adjektiv antyder, och det är värt att säga rakt ut:
Dessa fyra är också, precis, de egenskaper som en frontend-monolit saknar, oavsett hur modern backend-lösningen bakom den är. Vår guide till mjukvaruarkitektur visar var avvägningen ligger vid olika teamstorlekar.
En frontend-monolit är klientsidan av en webbapplikation som byggts från en enda kodbas. Många produkter kör fortfarande en sådan, även produkter vars backend är helt uppdelad. Serversidan är modulär; frontenden förblir en helhet.
För ett eller två team är det rätt upplägg. Sanningen att säga är det oftast rätt upplägg längre än vad folk tror. Symptomen visar sig när antalet team som arbetar i kodbasen växer, och de är tillräckligt specifika för att kunna identifieras:
En frontend-monolit begränsar med andra ord den oberoende leverans som var anledningen till att ni valde mikrotjänster. Det är det gapet som mikro-frontends överbryggar. Och det är värt att vara rakt på sak när det gäller gapets natur: det är organisatoriskt. Om fördröjningen ligger i granskningskulturen eller i en ändringsgrupp snarare än i kodbasen, kommer en uppdelning av kodbasen inte att lösa problemet.
Oberoende driftsättning hjälper bara om leveransprocessen bakom är disciplinerad, vilket är där bästa agila praxis gör rätt för sig.
Med mikro-frontend kan företag:
Detta passar team som redan arbetar med oberoende leverans i backend. Vinsterna är verkliga, men var och en av dem kommer med en kostnad som beskrivs i nästa avsnitt.
Listan över fördelar med denna arkitektur kan göras lång. I praktiken kokar de ner till fyra vinster, där varje vinst bygger på en specifik mekanism och ett visst villkor.
Kostnaderna är samma fyra egenskaper sedda från andra hållet. Ingen av dem är ett skäl att undvika arkitekturen. Alla kräver en ägare innan du sätter igång.
De två arkitekturerna löser olika problem. Här är en snabb överblick av avvägningarna – se det som "vilken begränsning arbetar du faktiskt under?" snarare än "vilken är bäst".
| Dimension | Monolitisk frontend | Mikro-frontend |
|---|---|---|
| Kodbas | Ett gemensamt arkiv (repository) som alla ändrar i | Flera självständigt ägda delar |
| Driftsättning (Deployment) | En gemensam pipeline / releasetåg | Pipeline per del, driftsätt vid behov |
| Teampassform | Ett eller två team | Tre, fyra eller fler självständiga team |
| Releasefrekvens | Begränsas av den långsammaste ändringen i batchen | Varje del släpps när den är klar |
| Skadeområde (Blast radius) | En regression kan sänka hela frontenden | Begränsad till en enskild del |
| Teknologi | Gemensamt ramverk och versioner; en uppgradering är ett projekt för hela produkten | Val per del; en uppgradering testas först på en del |
| Buntstorlek (Bundle size) | En samlad leverans, ingen duplicering | Bara koden som sidan behöver — men risk för duplicerade kopior av ramverk |
| Testning | Enklare end-to-end: en enhet att testa | Delar testas i isolering; den sammansatta produkten behöver sin egen e2e-testsvit |
| Löpande plattformskostnad | Ingen utöver själva applikationen | Skal (Shell) + komposition + designsystem + e2e-svit (≈ en utvecklare plus en ansvarig för designsystemet) |
| Bäst när | Konflikter vid releaser inte är din flaskhals | Flera självständiga team står i kö för att driftsätta till samma kodbas |
Den affärsmässiga kalkylen handlar om en avvägning mellan koordineringskostnader och leveranshastighet, och den går bara ihop vid en viss skala. Siffrorna nedan är vägledande snarare än universella. Själva balansen i avvägningen är viktigare än de exakta talen.
Arkitektur med mikro-frontends har tydliga fördelar, men det är ingen universallösning. Alla webbapplikationer passar inte för detta arbetssätt, och de avgörande faktorerna är lika mycket organisatoriska som tekniska.
Innan vi inför mikro-frontends låter vi kandidaten genomgå tre kontrollsteg. Om något av dem inte uppfylls är monoliten fortfarande det bättre alternativet, och det steget blir då det arbete som måste göras först.
Två stödjande villkor är också viktiga. Separata teknikstackar för olika moduler bör vara ett genuint krav snarare än en preferens, och budgeten måste täcka de löpande plattformskostnader som nämnts ovan.
Om du är osäker på om mikro-frontends passar ditt projekt, gå igenom de tre kontrollstegen tillsammans med någon som har genomfört en liknande migrering tidigare. I slutändan beror det på detaljerna i din affärsplan, inte på arkitekturens fördelar i teorin.
Att dela upp frontend är den enkla biten. Vad som avgör om resultatet håller ihop ligger i fyra områden som ingen enskild del äger, och varje område kräver ett beslut före den första migreringen snarare än efter.
Verktygskomponenter som hanterar tillstånd eller kommunicerar med applikationsmiljön, snarare än att rendera något, kan laddas vid behov precis som vilken annan del som helst. De saknar oftast användargränssnitt, vilket gör dem lätta att förbise när du bestämmer vem som äger vad.
Du kan integrera mikrofrontends på två sätt: vid byggtid eller vid körtid.
Containern installerar varje del som ett bibliotek, ungefär som när du installerar ett paket från npm, pakethanteraren för Node.js. Det är så här det mesta av dagens kod skrivs, och det är den enklaste lösningen som fungerar.
Nackdelarna är anledningen till att de flesta team går vidare från detta. Flera versioner av delade bibliotek måste hållas synkroniserade, vilket leder till byggproblem när de inte är det. Det är svårt att kombinera flera tekniker. Det slutgiltiga paketet innehåller alla beroenden, vilket gör det stort. Och eftersom varje ändring i ett beroende innebär att containern måste byggas om och distribueras på nytt, förblir containern och alla dess delar tätt sammankopplade. Vilket är just den koppling som arkitekturen är till för att eliminera.
Integrering vid körtid sätter ihop sidan från oberoende distribuerade delar medan den levereras, eller efter att den har laddats, så att en del kan släppas utan att containern behöver byggas om. Det finns tre typer av komposition:
@module-federation/nextjs-mf plugin har bara haft stöd för den äldre Pages Router, aldrig för standardalternativet App Router, och dess underhållare har flaggat för att stödet upphör omkring slutet av 2026. För projekt som använder App Router är Vercels officiella @vercel/microfrontends paket – byggt på en Multi-Zones-modell snarare än sammanslagning av kodstycken vid körtid – numera den rekommenderade vägen. single-spa förblir det främsta alternativet när delar byggs med olika ramverk.En micro frontend är en del av ett webbgränssnitt som byggs och driftsätts fristående av det team som ansvarar för den. Istället för en enda frontend-kodbas som alla ändrar i, sätts sidan samman av flera oberoende delar vid byggtid eller direkt i webbläsaren. Varje team kan leverera utan att behöva vänta på de andra.
Välj monoliten såvida inte release-köer är ert faktiska flaskhals. En enhetlig frontend-kodbas är enklare att bygga, testa och förstå, och det är oftast det rätta valet för ett eller två team. Micro frontends blir lönsamma först när flera autonoma team står i kö för att driftsätta samma kodbas, och det är kön, inte koden, som saktar ner er.
Utöver själva teamen bör ni budgetera för en fast plattformskostnad: för skalet, kompositionslagret, ett gemensamt designsystem och en testsvit för hela flödet. I de projekt vi ser motsvarar detta ungefär en ingenjörs fulla kapacitet plus en ansvarig för designsystemet, och den kostnaden kvarstår även efter lansering. Vinsten som motiverar detta är kortare ledtider, inte minskat antal anställda.
Tre eller fyra autonoma frontend-team är den vanliga tröskeln, och autonomi är viktigare än antalet. Om varje release fortfarande måste godkännas av en ledare eller en förändringsgrupp, tar ni bort en flaskhals som inte var det verkliga hindret genom att dela upp frontenden. Ett enskilt team som inför micro frontends får de operativa kostnaderna för ett distribuerat system utan att få några av de organisatoriska fördelarna.
Tre stycken återkommer ofta. Att skicka med en kopia av ramverket för varje del, vilket gör att sidan blir långsammare än monoliten den ersatte. Att lämna designsystemet utan ägare, vilket gör att gränssnittet ser inkonsekvent ut mellan olika delar. Och att låta versioner glida isär mellan oberoende driftsatta delar, vilket ofta bara upptäcks i produktion. Alla tre är brister i styrning snarare än tekniska problem.
Det kan gå åt båda hållen. Att dela upp applikationen innebär att webbläsaren bara laddar ner den kod som behövs för sidan, vilket är en fördel. Dubblerade beroenden mellan olika delar drar åt motsatt håll och kan göra den totala datamängden större än tidigare. Vilken effekt som vinner beror på om delade beroenden hanteras medvetet, så mät sidhastigheten för varje release istället för att anta att det går snabbare.
Ja, och det är den säkrare vägen. Placera ett skal framför den befintliga monoliten, bryt ut en vertikal del med tydliga gränser och låt ett team ansvara för den från början till slut. Varje efterföljande del följer samma mönster. Räkna med att migreringen tar kvartal snarare än sprintar, och behåll möjligheten att avbryta processen halvvägs.
Mikrofrontend ger frontend vad mikrotjänster gav backend: oberoende leverans genom att byta ut samordningskostnader mot leveranshastighet. Den avvägningen lönar sig bara i stor skala: plattformen medför en fast kostnad och felen är snarare organisatoriska än tekniska. Gå därför igenom de tre kontrollstationerna först: antal team och autonomi, domänavgränsning samt driftsmognad. Om en av dem brister är det mer värdefullt att åtgärda det, och monoliten förblir det bättre alternativet tills vidare.
Vi har byggt, underhållit och migrerat både mikrofrontend och monoliter, och vi hjälper gärna er verksamhet att gå igenom de tre kontrollstationerna, även i de fall då svaret är att stanna kvar där ni är. Kontakta oss så tar vi en titt.
Alexandra Mendes är Senior Growth Specialist på Imaginary Cloud med 3+ års erfarenhet av att skriva om mjukvaruutveckling, AI och digital transformation. Efter att ha avslutat en frontend-utvecklingskurs tog Alexandra upp några praktiska kodningskunskaper och arbetar nu nära med tekniska team. Alexandra brinner för hur ny teknik formar affärer och samhälle och tycker om att förvandla komplexa ämnen till tydligt och användbart innehåll för beslutsfattare.
Din dagliga webbutvecklare som gillar att gömma sig i backend. Javascript och Ruby är min sylt. Jag fumlar fortfarande med Docker och mina byggnader går sönder ganska ofta.
People who read this post, also found these interesting:
