Hur mikrofrontends fungerar: Arkitektur, mönster och exempel

Hem » Python » Hur mikrofrontends fungerar: Arkitektur, mönster och exempel

Mikrofrontends har blivit ett av de mest omtalade frontend-arkitekturmönstren. för team som växte ur den klassiska monoliten med en sida. När du har dussintals utvecklare som använder samma kodbas, saktar releasecyklerna ner, regressioner smyger sig in överallt och små UI-förändringar kräver plötsligt massiv samordning. Mikrofrontends angriper just det problemet genom att dela upp UI:et i oberoende byggda och driftsatta delar.

I den här guiden går vi igenom vad mikrofrontends är, varför de dök upp och hur de relaterar till mikrotjänster., vilka kärnidéer du bör respektera när du utformar dem, och hur de fungerar i praktiken med tekniker som React, Angular, Next.js, Web Components, Webpack Module Federation och Single-SPA. Vi kommer också att fördjupa oss i verkliga arkitekturmönster, god praxis, vanliga fallgropar och konkreta exempel som en produktkatalog och varukorg implementerade som separata mikrofrontends.

Vad är mikrofrontender och varför dök de upp?

Termen "mikrofrontends" populariserades runt 2016 i ThoughtWorks Technology Radar som ett svar på en mycket konkret trend: backend-arkitekturer övergick till mikrotjänster, men webbläsarsidan förblev en stor, spröd monolit som ägdes av ett enda team. Med tiden blir det där "feta klient"-SPA:t svårt att utveckla, även om backend-systemet är snyggt uppdelat i små tjänster.

En mikrofrontend är i huvudsak den mikrotjänstidé som tillämpas på webbläsarens användargränssnitt.Istället för ett stort frontend-arkiv består användargränssnittet av flera mindre, självständiga applikationer. Var och en äger en tydlig affärsdomän (till exempel "kassa", "produktsökning", "studentprofiler") och kan byggas, testas och driftsättas i sin egen takt.

Precis som mikrotjänster delar upp backend-logik i separata utplacerbara enheter, delar mikrofrontend upp frontend i vertikala skivor. som sträcker sig från databasen eller API:erna, via backend, upp till användargränssnittet. Ett tvärfunktionellt team äger den vertikala delen från början till slut, från dataschema till UI-komponenter.

Denna "vertikala organisation" står i kontrast till en horisontell uppdelning i lager (ett team för UI, ett annat för API:er, ett annat för databas). Vertikala team tenderar att leverera snabbare eftersom de inte behöver koordinera varje liten förändring över halva företaget.

Ur ett applikationsperspektiv är en mikrofrontend en autonom webbapplikation som kan sammansättas till en större upplevelse: den kan ha sin egen routing, tillståndshantering, designsystem och distributionspipeline, så länge den respekterar en uppsättning kontrakt med resten av systemet (URL:er, händelser, API:er, delade bibliotek, etc.).

Kärnidéer och principer bakom mikrogränssnitt

Flera återkommande principer dyker upp i framgångsrika mikrofrontend-arkitekturerDet är inga strikta regler, men de kommer att bespara dig mycket smärta om du använder dem som skyddsräcken.

Teknikagnosticism är en av de mest kända principerna: varje team ska kunna välja och uppgradera sin teknikstack utan att synkronisera med alla andra. Kanske finns en mikrofrontend på React, en annan i Angular och en äldre i Vue. Webbläsarbaserade abstraktioner som anpassade element (webbkomponenter) hjälper till att dölja dessa skillnader bakom ett standardiserat DOM-API.

Stark isolering mellan teamens kodbaser är ett annat viktigt mål.Idealiskt sett delar inte mikrofrontends en JavaScript-körtid eller globala variabler. Varje paket är självständigt, laddar sina egna beroenden och förlitar sig inte på dolda tillstånd från andra. Det minskar oavsiktlig koppling och gör oberoende distributioner mycket mer realistiska.

För att undvika namnkonflikter kommer team ofta överens om explicita namnrymder. för CSS-klasser, DOM-händelser, localStorage-nycklar, cookies eller till och med taggnamn för anpassade element. Till exempel kan ett utcheckningsteam prefixa saker med chk- eller använd en tagg som <blue-buy>, medan ett rekommendationsteam använder rec- or <green-recos>Vid första anblicken visar DOM vem som äger vilken pjäs.

En annan princip är att föredra inbyggda webbläsarfunktioner framför anpassade globala API:erIstället för att uppfinna ett allsidigt PubSub-system kan du förlita dig på vanliga DOM-händelser, CustomEvent, historik-API för routing eller själva DOM:en som integrationslager. När du verkligen behöver ett delat API, håll det så litet och stabilt som möjligt.

Slutligen bör motståndskraft vara en del av designen från dag ettVarje mikrofrontend bör fortfarande leverera ett visst värde när JavaScript är långsamt, misslyckas eller blockeras. Tekniker som serversidesrendering, progressiv förbättring och skelettskärmar hjälper till att hålla den upplevda prestandan hög även under dåliga nätverksförhållanden.

Vad är en "modern webbapplikation" i det här sammanhanget?

Inte alla webbplatser behöver mikrogränssnitt eller en komplex strategi för webbläsarintegrationEn bra mental modell kommer från "dokument-till-applikations-kontinuumet": till vänster har du mestadels statiska dokument länkade samman; till höger har du helt interaktiva appar som en online-bildredigerare.

Om ditt projekt är mer statiska dokument räcker det ofta med en enkel serverrenderad komposition.Servern samlar HTML-fragment från olika källor, sammanfogar dem och skickar dem till webbläsaren. Uppdateringar sker via fullständiga sidladdningar eller små Ajax-injektioner, och det är helt okej.

När du går mot mer dynamiska, appliknande upplevelser—omedelbar feedback, arbete offline, optimistiska UI-uppdateringar — ren serversidesintegration slutar att räcka till. Du behöver klientsideskomposition, tillståndshantering och routing. Det är där mikrofrontends blir intressanta: de ger dig ett sätt att skala den komplexiteten över många team.

Vertikal organisation och domänstyrda skivor

En vanlig rekommendation är att anpassa mikrogränssnitt till affärsdomäner istället för tekniska lager.Tänk i termer av användarresor: ”varukorg”, ”produktinformation”, ”administratörsanvändare”, ”kursscheman”, ”studentregister”, ”fakturor” etc.

Var och en av dessa domäner kan bli sin egen mikrofrontend med ett väldefinierat ansvarI ett universitetssystem skulle en app kunna hantera studentprofiler, en annan personalprofiler, en tredje kursscheman och en annan gränssnittet för tentamensresultaten. De delar ett skal och kanske lite stil, men var och en är en oberoende applikation ur ett driftsättningsperspektiv.

Bra slicing tar även hänsyn till begränsade kontexter för dina backend-mikrotjänster.Idealiskt sett kommunicerar mikrogränssnittet för "fakturering" huvudsakligen med faktureringsmikrotjänsterna, "katalog"-gränssnittet kommunicerar med katalogtjänster och så vidare. Det håller varje vertikal del sammanhängande och minskar beroenden mellan team.

Teknisk integration: DOM som API och webbkomponenter

I webbläsarbaserade mikrofrontend-arkitekturer fungerar DOM-systemet ofta som det primära integrations-API:et.Istället för att anropa varandras JavaScript-koder direkt exponerar teamen funktionalitet genom HTML-element, attribut och händelser.

Anpassade element (en del av webbkomponenter) är en kraftfull primitiv för dettaEtt team kan bygga en funktion med hjälp av vilket ramverk de vill och sedan omsluta den som en anpassad tagg, till exempel. <order-minicart></order-minicart>Det offentliga kontraktet för den komponenten definieras av dess taggnamn, attribut och emitterade händelser, inte av dess interna implementering.

Webbläsarstöd för Custom Elements v1 är nu stabilt i alla större webbläsare, vilket innebär att du sällan behöver polyfills. De flesta vanliga ramverk – React, Vue, Angular, Svelte, Preact – kan rendera eller bädda in anpassade element som om de vore vanliga HTML-taggar, och många av dem kan också kompileras till ett anpassat element i sig.

Integrationsmönstret ser ut ungefär så härEn mikrogränssnitt för "produktsida" avgör vilka funktioner som visas på sidan (väljare, köpknappar, minivarukorg, rekommendationer). Den injicerar anpassade element som <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>De team som äger dessa funktioner registrerar sina element hos customElements.define och implementera livscykelåteranrop som connectedCallback or attributeChangedCallback.

När en produktvariant ändras kan sidan antingen återskapa elementet eller bara uppdatera dess attribut.Om komponenten observerar relevanta attribut kan den rendera om sig själv. Internt kan komponenten använda mallsträngar, React, Vue eller någon annan renderingsmotor; integratorn behöver inte bry sig.

Klientkommunikation: händelser och DOM-relationer

Att skicka attribut fungerar bra för enkelriktade "data in"-scenarier, men många verkliga interaktioner kräver att komponenterna kommunicerar tillbaka till sin omgivning eller till syskon. Ett typiskt exempel är en "köp"-knapp som måste meddela minivarukorgen när en vara läggs till.

Istället för att bygga en anpassad global händelsebuss kan du luta dig mot webbläsarhändelserLeverans av komponenter CustomEvent instanser som bubblar upp genom DOM-trädet. Ett föräldraelement eller till och med window kan lyssna efter dessa händelser och orkestrera svar.

Till exempel kan köpknappen utlösa en händelse som blue:basket:changed med den aktuella vagnens nyttolastMinivagnen prenumererar på det evenemanget den window eller på ett delat containerelement och uppdaterar dess interna tillstånd närhelst det utlöses.

Denna metod håller komponenterna oberoendeKöpknappen har ingen aning om vem, om någon, som lyssnar efter dess händelser. Den uppfyller bara sitt kontrakt. Och minivarukorgen är bara beroende av händelsesemantik, inte av implementeringsdetaljerna för andra fragment.

Serversidesrendering och universella komponenter

Om du bryr dig om prestanda i första omgången, SEO eller motståndskraft när JavaScript misslyckas, är serverside rendering (SSR) avgörande.Rena webbkomponenter på klientsidan visas bara efter att JS-paketet har laddats ner och körts, vilket kan innebära en vit skärm på långsamma nätverk.

En pragmatisk lösning är att kombinera anpassade element med serversidesinkluderingar (SSI/ESI).Varje mikrofrontend exponerar en HTTP-slutpunkt som returnerar HTML-koden för sitt fragment, till exempel /blue-buy?sku=t_porscheHuvudsidan, som renderas av ett shell- eller värdprogram, innehåller platsmarkörer som <!--#include virtual="/blue-buy?sku=t_porsche" --> som webbservern (ofta nginx) expanderar innan svaret skickas till webbläsaren.

Vid körning i webbläsaren hydreras eller ominitialiseras samma anpassade element när dess JS-paket laddas. Det ger dig en "universell" komponent: den kan renderas på servern för hastighet och SEO, och sedan bete sig som ett helt interaktivt anpassat element på klienten.

En nackdel med SSR med inkluderingar är att det långsammaste fragmentet dikterar den totala svarstidenCachning på fragmentnivå är nästan obligatoriskt. För dyra, mycket personliga delar (som rekommendationer) kan du hoppa över serversidans rendering och ladda dem asynkront på klienten.

Skelettskärmar är en bra kompromiss för att undvika störande layoutförändringarEtt fragment kan serverrendera en gråmarkerad platshållare med ungefär samma storlek som det slutliga innehållet. När de verkliga data anländer på klientsidan byts skelettet ut utan större omflöden.

Datainläsning och upplevd prestanda

I en mikrofrontendvärld måste man noggrant tänka på var och när data hämtas.Du kan hämta allt på serversidan, allt på klientsidan eller använda en hybrid. Varje val påverkar cachningsstrategier, tid till interaktion och upplevd hastighet.

Serversidan inkluderar naturligtvis uppmuntran till serversideshämtningar per fragmentVarje mikrofrontend kommunicerar med "sina" backend-tjänster, renderar HTML och returnerar den till skalet. Den HTML-koden kan cachas oberoende av andra fragment, vilket hjälper till att skala högtrafikerade delar som inloggning eller produktlistningar.

När du laddar data på klienten bör du budgetera för progressiva tillstånd: initialt skelett, snabba uppdateringar när attribut ändras och reservbeteende när API:er är långsamma. Ibland är det mindre visuellt störande att behålla gammal data på plats tills ny data anländer än att visa ett skelett för varje mindre ändring.

Mikrofrontends med React

React är ett mycket populärt val för att implementera mikrofrontends på grund av dess ekosystem och renderingsoptimeringar.Den virtuella DOM:n och diffingen gör det enkelt att uppdatera små delar av användargränssnittet baserat på prop-ändringar eller globalt tillstånd, och du kan paketera React-appar antingen som fristående SPA:er eller som anpassade element.

Migrering mellan React-versioner tenderar att vara stegvis och relativt smärtfri jämfört med vissa andra ramverk, vilket är användbart när många oberoende team underhåller separata mikrofrontends. Du behöver inte att alla fragment hoppar från en huvudversion till en annan samtidigt.

Baksidan är att decentraliserade React-mikrofrontender kan skapa resursspridning.flera team, flera CI/CD-pipelines, många paket, många små repos. Utan tillräckligt med automatisering för byggande, provisionering och observerbarhet blir den omkostnaden svår att hantera.

En annan praktisk fråga är buntstorlekenOm varje mikrofrontend levererar sin egen kopia av React och delade bibliotek kan den totala nedladdningsstorleken explodera, särskilt när flera fragment behövs för att rendera en sida. Lösningar som Module Federation (för att dela beroenden vid körning) eller en starkt anpassad stack mellan team kan mildra detta.

Mikrogränssnitt med Angular

Angular lämpar sig bra för mer opinionsbildande mikrofrontend-uppsättningar, särskilt när du använder monorepos och verktygen kring dem (som Nx). Angular-arbetsytor är organiserade i projekt och bibliotek, vilket gör det naturligt att dela upp en stor lösning i flera appar och delade bibliotek.

Sedan Angular 12 och Webpack 5 har Module Federation blivit en förstklassig medborgareEtt Angular-projekt kan konfigureras som en värd eller en fjärrkontroll med hjälp av schematiska kommandon, vilket kopplar in nödvändiga webpack.config.js och bootstrap-logik för dig.

I den här modellen fungerar Angular-appen som "värd" som skal som orkestrerar navigering, delat tillstånd och beroendedelning. Enskilda Angular-mikrofrontends (fjärrkontroller) exponerar Angular-moduler som värden kan lata dynamiskt via Module Federation.

De vanliga Angular-routingprimitiverna gäller fortfarandeInom en mikrogränssnitt använder du RouterModule.forChild för definitioner av underordnade rutter så att värden är den enda som använder forRootPå så sätt kan flera Angular-appar samexistera under ett enhetligt URL-utrymme utan routerkonflikter.

Modulfederation i praktiken (Angular-exempel)

Webpack Module Federation är en Webpack 5-funktion som gör det möjligt för flera byggen att dela kod vid körning.En version (värden) laddar dynamiskt moduler som exponeras av andra versioner (fjärrkontroller) via en liten manifestfil, vanligtvis med namnet remoteEntry.js.

I Angular kan du bygga upp detta ganska snabbtDu kan till exempel skapa en värdapp (host-app) och kör sedan ett schema som ng add @angular-architects/module-federation --project host-app --port 4200Detta konfigurerar en ModuleFederationPlugin, startfiler och runtime-logik.

Sedan skapar du två fjärranslutna Angular-appar: en för en produktkatalog och en för en kundvagnVarje app får sin egen port (t.ex. 4201 för products-app, 4202 för cart-app) och dess egen modulfederationskonfiguration. I webpack.config.js för varje fjärrkontroll du använder exposes att publicera en modul (vanligtvis huvudappens modul) under en nyckel som ./ProductsModule or ./CartModule.

Värdskalet definierar sedan rutter som långsamt laddar dessa fjärrmoduler. via loadRemoteModule från @angular-architects/module-federationTill exempel att navigera till /products utlöser en dynamisk import från http://localhost:4201/remoteEntry.js och laster ProductsModule; /cart gör samma sak med vagnens fjärrkontroll.

Inuti katalogens mikrogränssnitt kan du ha en ProductsComponent som återger en tabell med objekt, läser data från en PRODUCTS_CATALOG konstant och erbjuder en knapp som visar "Lägg till i varukorgen". När du klickar lagras varan i localStorage under en "varukorg"-knapp, vilket ökar kvantiteterna när produkten redan finns.

Varukorgens mikrogränssnitt läser sedan från samma localStorage nyckel, visar en tabell med produktnamn, pris, kvantitet och totalsumma, och erbjuder en knapp för "Rensa varukorg" som rensar lagringsutrymmet och återställer dess interna tillstånd. Detta är ett enkelt men illustrativt sätt att dela tillstånd mellan två oberoende appar utan tät koppling.

Bygga värdskalet: layout, startsida och navigering

Ett stabilt värdskal är avgörande för en bra användarupplevelse över mikrogränssnittDen äger vanligtvis den globala layouten (sidhuvud, sidfot, sidofält), routning på toppnivå och ibland globala tillstånd som autentisering eller funktionsflaggor.

I Angular-exemplet definierar värden en LayoutComponent som renderar en rubrik och en kapslad router-outletRubriken lever i sin egen HeaderModule och exponerar navigeringslänkar till startsidan, produktlistan och varukorgen via Angulars routerLinkRuttvägar kan centraliseras i en enum som RoutesPath för att undvika magiska strängar.

Layout-ruttmodulen konfigurerar en överordnad rutt med LayoutComponent som dess komponent och definierar underordnade rutter för /home, /products och /cart. De /home sökvägen laddar en lokal HomeModule; de andra använder loadRemoteModule för att hämta Angular-mikrofrontenderna vid körning.

Inom värden, en SharedModule kan samla återanvändbara byggstenar som rubrik, layout, vanliga direktiv och konstanter. Denna modul kan importeras till roten. AppModule tillsammans med AppRoutingModule, som pekar den tomma sökvägen till layoutens routningskonfiguration.

Next.js och mikrogränssnitt

Next.js, som React-ramverket i produktionsklass, fungerar också bra med en mikrofrontend-metod., särskilt eftersom den antog Webpack 5 och därmed stöd för Module Federation. Dess fokus på SSR, stegvis statisk regenerering och routing gör den till en bra kandidat för skalet, individuella mikrofrontends eller båda.

För att implementera mikrofrontends i Next.js konfigurerar du vanligtvis Module Federation på Webpack-nivå., exponera vissa sidor eller komponenter som fjärrkontroller och konsumera dem från en värd. Även om Module Federation "bara" är en JavaScript-bundlingsfunktion, kan du tänka på den som ett arkitektoniskt mönster: den låter dig dynamiskt ladda kod som ägs av olika team utan att paketera ihop allt i förväg.

För äldre Next.js-versioner utan Webpack 5 skulle du behöva externa adaptrar. för att aktivera federationsstöd. Från och med Next 10.2 är Webpack 5-stöd inbyggt, vilket förenklar installationen dramatiskt.

Single-SPA och andra mikrofrontend-ramverk

Single-SPA är en annan välkänd lösning för mikrofrontends, särskilt i React-ekosystem.Den fokuserar på att orkestrera flera oberoende appar på samma sida, där var och en är monterad i sin egen DOM-nod baserat på den aktuella rutten.

Med Single-SPA kan du ha flera React-applikationer (eller till och med blanda React, Vue och Angular) samtidigt.Ramverket hanterar när varje mikrofrontend ska startas, monteras eller avmonteras allt eftersom användaren navigerar, och du kopplar in det i din routingstrategi (till exempel med React Router i varje fragment).

När du väljer mellan Single-SPA och Module Federation, team överväger ofta sina preferenser för paketering/verktyg. Modulfederation integreras djupt med Webpack (och i allt högre grad med alternativ som Rspack eller Rollup när de lägger till stöd). Single-SPA, å andra sidan, handlar mer om runtime-orkestrering än paketdelning, så du kan använda det med olika byggverktyg samtidigt som du hanterar koddelning på andra sätt.

Mål, funktioner och fördelar med mikrofrontends

Huvudsyftet med mikrofrontends är att skala frontend-utveckling över många team utan att kollapsa under koordineringskostnader.Istället för en gigantisk kodbas med synkroniserade utgåvor får du mindre, oberoende utplacerbara enheter.

Viktiga mål inkluderar vanligtvis möjliggöra för flera team att arbeta parallellt, stödja oberoende distribution för olika delar av användargränssnittet, bibehålla flexibilitet att använda olika tekniker där det är lämpligt och förbättra underhållbarheten genom att minska storleken och komplexiteten hos varje kodbas.

Typiska egenskaper hos en sådan arkitektur är återanvändning av komponenter genom delade bibliotek, modulär integration via ett applikationsskal, oberoende pipelines per mikrofrontend, prestandaoptimering via CDN och cachning, centraliserad säkerhetshantering och stark observerbarhet.

Ur ett affärsperspektiv är fördelarna betydandeUtveckling skalas bättre med fler team, fel isoleras bättre, funktioner kan rullas ut eller tillbaka per domän, och äldre frontend-stackar kan migreras gradvis genom att ersätta en skiva i taget istället för att skriva om hela appen.

Viktiga komponenter i en mikrofrontend-arkitektur

Även om implementeringarna varierar, delar de flesta mikrofrontend-arkitekturer några strukturella komponenter. som håller allting sammanhängande.

Applikationsskalet (eller containern) är ryggradenDen äger den yttre layouten, global navigering, autentisering, ibland globalt tillstånd och logiken för att ladda eller lossa mikrogränssnitt. I webbläsarbaserade inställningar är det sidan som hämtar alla andra paket.

Varje mikrogränssnitt är en fristående modul som implementerar en specifik funktion, såsom produktkatalog, kundvagn, användarprofil eller administratörspanel. Den exponerar en integrationsyta (rutter, anpassade element, modulfederationsfjärrkontroller) och döljer interna detaljer från resten av systemet.

En händelsebuss eller ett meddelandesystem finns ofta för kommunikation mellan mikrofronterDetta kan vara en enkel abstraktion över DOM-händelser, en centraliserad Redux-lagring eller en anpassad meddelandemäklare. Målet är frikopplad publicerings-/prenumerationssemantik: en mikrofrontend genererar händelser utan att veta vem som hanterar dem.

Delade bibliotek innehåller återanvändbara UI-komponenter, verktyg, designtokens och gemensamma klienterI monorepo-inställningar lyser verktyg som Nx igenom här, vilket låter dig definiera delade paket som konsumeras av flera appar med påtvingade gränser och konsekventa versioner.

Observerbarhetsinsamlare och verktyg (till exempel med OpenTelemetry) aggregerade loggar, mätvärden och spår från alla mikrogränssnitt, vilket gör det möjligt att diagnostisera problem som sträcker sig över flera fragment eller tjänster.

CDN:er kompletterar bilden på leveranssidan, cacha statiska tillgångar som JS-paket, CSS och bilder nära användarna, vilket minskar latens och avlastar ursprungsservrar. I mikrofrontend-konfigurationer hostar du ofta varje fragments tillgångar på en egen CDN-sökväg för oberoende cachning och utrullningar.

Arkitektur- och designmönster för mikrogränssnitt

Det finns en omfattande katalog med mönster som specifikt gäller för mikrofrontends., vanligtvis definierade av hur du komponerar, distribuerar och ansluter dem.

Komponentbaserad komposition innebär att bygga användargränssnittet utifrån webbkomponenter eller liknande primitiverVarje komponent har ett enda ansvar, tydliga indata och utdata, och kan testas isolerat. Ett kompositionslager på högre nivå (som ett skal eller ett orkestreringsramverk) arrangerar dessa komponenter till hela sidor.

Federationsmönstret betonar fullständig applikationsautonomiVarje mikrofrontend är en fristående app med sin egen livscykel och sitt eget team; skalet eller en API-gateway dirigerar helt enkelt förfrågningar/data till rätt fragment. Kommunikation sker via väldefinierade REST API:er eller händelser.

Applikationsskalmönstret är i praktiken "värd"-metodenSkalet laddar mikrogränssnitt, hanterar övergripande problem som navigering och säkerhet och säkerställer ett enhetligt utseende och känsla. Detta är mycket vanligt med modulfederation eller Single-SPA-baserade konfigurationer.

API-gateway och Backend-for-Frontend (BFF)-mönster fokuserar på serversidanEn API-gateway sitter framför många backend-tjänster, routar förfrågningar och tillämpar säkerhet. En BFF går längre: varje frontend (webb, mobil, IoT) kan få sin egen dedikerade backend skräddarsydd efter sina behov.

Distribuerade datalagringsmönster erkänner att olika mikrogränssnitt kan hantera sina egna datakällor eller cachar. I webbläsaren innebär detta ofta att man använder separata localStorage-nycklar, IndexedDB-databaser eller minneslager, medan det på backend-plattformen innebär separata databaser per mikrotjänst.

Observerbarhet, oberoende distribution, horisontell skalbarhet och säkerhetsmönster ta itu med operativa problem: hur man övervakar varje fragment, hur man distribuerar dem utan globala avbrott, hur man skalar dem under belastning och hur man konsekvent framtvingar autentisering/auktorisering.

Routingkomposition och lata laddningsmönster är centrala för UX och prestandaEn masterrouter bestämmer vilken mikrofrontend som hanterar vilken sökväg, och varje mikrofrontend har sin egen interna router. Lazy loading säkerställer att du bara laddar ner koden för de fragment som faktiskt behövs för den aktuella rutten.

Slutligen säkerställer händelsebaserade kommunikationsmönster att löst kopplade mikrogränssnitt fortfarande kan koordinera. genom domänhändelser, utan att introducera direkta beroenden som skulle omintetgöra poängen med modularitet.

När man ska använda mikrofrontends (och när inte)

Mikrogränssnitt lyser i stora, komplexa applikationer med väldefinierade funktionella domänerTänk e-handelsplattformar, företagsledningssystem, kommunala portaler, utbildningsplattformar, stora hälsoportaler eller vilken produkt som helst med många team som arbetar med separata funktionella områden.

De är särskilt användbara när du har flera team som arbetar parallellt som behöver autonomi i tekniska val, releasecykler och prioriteringar, eller när du långsamt moderniserar ett äldre frontend och inte har råd med en fullständig omskrivning. Du kan skapa ett område i taget till en ny mikrofrontend och integrera den med det gamla skalet.

De hjälper också till när olika delar av appen behöver skalas olika.En inloggnings- eller utcheckningssida kan få mycket mer trafik än en administratörskonfigurationsskärm; att skala dessa segment separat kan spara mycket infrastrukturkostnader.

Mikrofrontends är dock inte en gratis lunch.De ökar arkitekturens komplexitet, kräver stark samordning av UX och delade kontrakt, och introducerar nya fellägen (till exempel att ett fragment inte laddas). För små eller medelstora appar med ett enda team är en välstrukturerad monolit ofta enklare och mer kostnadseffektiv.

Team bör också vara försiktiga med "ramverksanarki"Även om det är tekniskt möjligt för varje mikrofrontend att använda en helt annan stack, gör en okontrollerad blandning av ramverk det svårare att anställa, verktygsbygga och dela kod. En rimlig nivå av anpassning (till exempel "vi är en React-first-butik, men vi tillåter Angular för specifika domäner") fungerar vanligtvis bättre i längden.

Mikrofrontends utvidgar mikrotjänsttänkandet till webbläsaren, vilket ger team ett sätt att dela upp stora frontends i autonoma, domänorienterade delar som kan utvecklas, distribueras och skalas oberoende samtidigt som de skapar en sammanhängande användarupplevelse när de kombineras via ett applikationsskal, delade bibliotek, modulfederation, webbkomponenter eller orkestreringsramverk som Single-SPA.