- Mikrofrontender anvender mikrotjenesteprinsipper i nettleserens brukergrensesnitt, og deler store frontender inn i autonome, domeneorienterte sektorer som eies av tverrfunksjonelle team.
- Integrasjon er avhengig av DOM, tilpassede elementer, modulføderasjon og et applikasjonsskall som orkestrerer ruting, sikkerhet, komposisjon og delte biblioteker.
- Rammeverk som React, Angular og Next.js, sammen med mønstre som BFF, hendelsesbusser og lazy loading, muliggjør skalerbare, robuste og observerbare mikrofrontend-systemer.
- Mikrofrontender øker arkitektonisk kompleksitet, men lønner seg i store produkter med flere team der uavhengig distribusjon, gradvis migrering og differensiert skalering er avgjørende.
Mikrofrontender har blitt et av de mest omtalte frontend-arkitekturmønstrene. for team som vokste fra den klassiske enkeltsidede monolitten. Når du har dusinvis av utviklere som berører den samme kodebasen, blir utgivelsessyklusene tregere, regresjoner sniker seg inn overalt, og små endringer i brukergrensesnittet krever plutselig massiv koordinering. Mikrofrontender angriper nettopp det problemet ved å dele brukergrensesnittet opp i uavhengig bygget og distribuert deler.
I denne veiledningen skal vi gå gjennom hva mikrofrontender er, hvorfor de dukket opp, og hvordan de relaterer seg til mikrotjenester., hvilke kjerneideer du bør respektere når du designer dem, og hvordan de fungerer i praksis med teknologier som React, Angular, Next.js, Web Components, Webpack Module Federation og Single-SPA. Vi vil også dykke ned i reelle arkitekturmønstre, god praksis, vanlige fallgruver og konkrete eksempler som en produktkatalog og handlekurv implementert som separate mikrofrontender.
Hva er mikrofrontender, og hvorfor dukket de opp?
Begrepet «mikro-frontends» ble popularisert rundt 2016 i ThoughtWorks Technology Radar som et svar på en veldig konkret trend: backend-arkitekturer gikk over til mikrotjenester, men nettlesersiden forble en stor, skjør monolitt eid av et enkelt team. Over tid blir det vanskelig å utvikle denne «fete klienten»-SPA-en, selv om backend-en er pent delt inn i små tjenester.
En mikrofrontend er i hovedsak mikrotjenesteideen som brukes i nettleserens brukergrensesnitt.I stedet for ett stort frontend-arkiv, setter du sammen brukergrensesnittet fra flere mindre, selvstendige applikasjoner. Hver av dem eier et tydelig forretningsdomene (for eksempel «kasse», «produktsøk», «studentprofiler») og kan bygges, testes og distribueres i sin egen takt.
Akkurat som mikrotjenester deler backend-logikk inn i separate utplasserbare enheter, deler mikrofrontender frontenden inn i vertikale skiver. som strekker seg fra databasen eller API-ene, via backend og opp til brukergrensesnittet. Et tverrfunksjonelt team eier den vertikale delen fra ende til ende, fra dataskjema til UI-komponenter.
Denne «vertikale organiseringen» står i kontrast til en horisontal lagdeling (ett team for brukergrensesnitt, et annet for API-er, et annet for database). Vertikale team har en tendens til å sende ut raskere fordi de ikke trenger å koordinere hver minste endring på tvers av halve selskapet.
Fra et applikasjonsperspektiv er en mikrofrontend en autonom webapplikasjon som kan settes sammen til en større opplevelse: den kan ha sin egen ruting, tilstandsadministrasjon, designsystem og distribusjonspipeline, så lenge den respekterer et sett med kontrakter med resten av systemet (URL-er, hendelser, API-er, delte biblioteker osv.).
Kjerneideer og prinsipper bak mikrofrontender
Flere tilbakevendende prinsipper dukker opp i vellykkede mikrofrontend-arkitekturer; det er ikke strenge regler, men de vil spare deg for mye smerte hvis du bruker dem som rekkverk.
Teknologiagnostisisme er et av de mest kjente prinsippene: hvert team skal kunne velge og oppgradere sin teknologistabel uten å synkronisere med alle andre. Kanskje én mikrofrontend er på React, en annen i Angular og en eldre i Vue. Nettleser-native abstraksjoner som Custom Elements (Web Components) bidrar til å skjule disse forskjellene bak et standard DOM API.
Sterk isolasjon mellom teamkodebaser er et annet viktig mål.Ideelt sett deler ikke mikrofrontender JavaScript-kjøretid eller globale variabler. Hver pakke er selvstendig, laster inn sine egne avhengigheter og er ikke avhengig av skjult tilstand fra andre. Det reduserer utilsiktet kobling og gjør uavhengige distribusjoner mye mer realistiske.
For å unngå navnekonflikter blir team ofte enige om eksplisitte navnerom. for CSS-klasser, DOM-hendelser, localStorage-nøkler, informasjonskapsler eller til og med taggnavn for tilpassede elementer. For eksempel kan et kasseteam sette prefikset for ting med chk- eller bruk en tagg som <blue-buy>, mens et anbefalingsteam bruker rec- or <green-recos>DOM forteller deg raskt hvem som eier hvilken brikke.
Et annet prinsipp er å foretrekke innebygde nettleserfunksjoner fremfor tilpassede globale API-erI stedet for å finne opp et allsidig PubSub-system, kan du stole på standard DOM-hendelser, CustomEvent, historikk-API for ruting eller selve DOM-en som integrasjonslag. Når du virkelig trenger et delt API, hold det så lite og stabilt som mulig.
Til slutt bør robusthet være en del av designet fra dag énHver mikrofrontend bør fortsatt levere en viss verdi når JavaScript er tregt, feiler eller er blokkert. Teknikker som gjengivelse på serversiden, progressiv forbedring og skjelettskjermer bidrar til å holde den opplevde ytelsen høy selv under dårlige nettverksforhold.
Hva er en «moderne webapplikasjon» i denne sammenhengen?
Ikke alle nettsteder trenger mikrogrensesnitt eller en kompleks strategi for nettleserintegrasjonEn god mental modell kommer fra «dokumenter-til-applikasjons-kontinuumet»: på venstre side har du stort sett statiske dokumenter koblet sammen; på høyre side har du fullt interaktive apper som et online bilderedigeringsprogram.
Hvis prosjektet ditt er nærmere statiske dokumenter, er en enkel server-rendered komposisjon ofte nok.Serveren samler HTML-fragmenter fra forskjellige kilder, setter dem sammen og sender dem til nettleseren. Oppdateringer skjer via full sideinnlasting eller små Ajax-injeksjoner, og det er helt greit.
Når du beveger deg mot mer dynamiske, applignende opplevelser– umiddelbar tilbakemelding, arbeid offline, optimistiske UI-oppdateringer – ren serversideintegrasjon er ikke lenger tilstrekkelig. Du trenger klientsidekomposisjon, tilstandsstyring og ruting. Det er der mikrofrontender blir interessante: de gir deg en måte å skalere den kompleksiteten på tvers av mange team.
Vertikal organisering og domenedrevne skiver
En vanlig anbefaling er å samkjøre mikrogrensesnitt med forretningsdomener i stedet for tekniske lag.Tenk i form av brukerreiser: «handlekurv», «produktdetaljer», «administratorbrukere», «kurstimeplaner», «studentjournaler», «fakturaer» osv.
Hvert av disse domenene kan bli sin egen mikrofrontend med et veldefinert ansvarI et universitetssystem kan én app administrere studentprofiler, en annen ansattprofiler, en tredje timeplaner og en annen brukergrensesnittet for eksamensresultater. De deler et skall og kanskje litt styling, men hver av dem er en uavhengig applikasjon fra et implementeringsperspektiv.
God slicing tar også hensyn til avgrensede kontekster for backend-mikrotjenestene dine.Ideelt sett kommuniserer mikrofrontenden for «fakturering» hovedsakelig med faktureringsmikrotjenestene, «katalog»-frontenden kommuniserer med katalogtjenester, og så videre. Det holder hver vertikale sektor sammenhengende og reduserer avhengigheter på tvers av team.
Teknisk integrasjon: DOM som API og webkomponenter
I nettlesersidede mikrofrontend-arkitekturer fungerer DOM-en ofte som det primære integrasjons-API-et.I stedet for å kalle hverandres JavaScript-koder direkte, eksponerer team funksjonalitet gjennom HTML-elementer, attributter og hendelser.
Tilpassede elementer (en del av webkomponenter) er et kraftig primitivt middel for detteEt team kan bygge en funksjon ved hjelp av hvilket som helst rammeverk de ønsker, og deretter pakke den inn som en tilpasset tag, for eksempel. <order-minicart></order-minicart>Den offentlige kontrakten for den komponenten er definert av dens tagnavn, attributter og utsendte hendelser, ikke av dens interne implementering.
Nettleserstøtte for Custom Elements v1 er nå solid på tvers av alle større nettlesere, noe som betyr at du sjelden trenger polyfills. De fleste vanlige rammeverk – React, Vue, Angular, Svelte, Preact – kan gjengi eller legge inn tilpassede elementer som om de var vanlige HTML-tagger, og mange av dem kan også kompileres til et tilpasset element i seg selv.
Integrasjonsmønsteret ser omtrent slik utEn mikrogrensesnitt for «produktside» bestemmer hvilke funksjoner som vises på siden (velgere, kjøpsknapper, minihandlekurv, anbefalinger). Den injiserer tilpassede elementer som <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>Teamene som eier disse funksjonene registrerer elementene sine hos customElements.define og implementere tilbakekall i livssyklusen, som connectedCallback or attributeChangedCallback.
Når en produktvariant endres, kan siden enten gjenskape elementet eller bare oppdatere attributtene.Hvis komponenten observerer relevante attributter, kan den gjengi seg selv på nytt. Internt kan komponenten bruke malstrenger, React, Vue eller en hvilken som helst gjengivelsesmotor; integratoren trenger ikke å bry seg.
Klientsidekommunikasjon: hendelser og DOM-relasjoner
Overføring av attributter fungerer bra for enveis «data inn»-scenarier, men mange reelle interaksjoner krever at komponenter snakker tilbake til omgivelsene sine eller til søsken. Et typisk eksempel er en «kjøp»-knapp som må varsle minihandlekurven når en vare legges til.
I stedet for å bygge en tilpasset global hendelsesbuss, kan du lene deg på nettleserhendelserUtsending av komponenter CustomEvent forekomster som bobler opp gjennom DOM-treet. Et overordnet element eller til og med window kan lytte etter disse hendelsene og orkestrere reaksjoner.
For eksempel kan kjøpsknappen utløse en hendelse som blue:basket:changed med gjeldende nyttelast for vognenMinivognen abonnerer på den hendelsen på window eller på et delt containerelement og oppdaterer den interne tilstanden hver gang den utløses.
Denne tilnærmingen holder komponentene uavhengigekjøpsknappen aner ikke hvem, om noen, som lytter etter hendelsene. Den oppfyller bare kontrakten sin. Og minihandlekurven er kun avhengig av hendelsessemantikk, ikke av implementeringsdetaljene til andre fragmenter.
Serverside-rendering og universelle komponenter
Hvis du bryr deg om ytelse i første omgang, SEO eller robusthet når JavaScript feiler, er serverside-rendering (SSR) avgjørende.Rene klientsidede webkomponenter vises bare etter at JS-pakken er lastet ned og kjørt, noe som kan bety en hvit skjerm på trege nettverk.
En pragmatisk løsning er å kombinere Custom Elements med server-side inclusions (SSI/ESI).Hver mikrofrontend eksponerer et HTTP-endepunkt som returnerer HTML-koden for fragmentet sitt, for eksempel /blue-buy?sku=t_porscheHovedsiden, gjengitt av et skall- eller vertsapplikasjon, inneholder plassholdere som <!--#include virtual="/blue-buy?sku=t_porsche" --> som webserveren (ofte nginx) utvider før den sender svaret til nettleseren.
Ved kjøring i nettleseren blir det samme tilpassede elementet hydrert eller initialisert på nytt. når JS-pakken lastes inn. Det gir deg en «universell» komponent: den kan gjengis på serveren for hastighet og SEO, og deretter oppføre seg som et fullstendig interaktivt tilpasset element på klienten.
En ulempe med SSR med inkluderinger er at det tregeste fragmentet dikterer total responstidMellomlagring på fragmentnivå er nesten obligatorisk. For dyre, svært personlige deler (som anbefalinger) kan du hoppe over gjengivelse på serversiden og laste dem inn asynkront på klienten.
Skjelettskjermer er et godt kompromiss for å unngå forstyrrende layoutendringerEt fragment kan gjengi en gråtonet plassholder med omtrent samme størrelse som det endelige innholdet på serveren. Når de virkelige dataene ankommer på klientsiden, byttes skjelettet ut uten store omlegginger av flyt.
Datainnlasting og opplevd ytelse
I en mikrofrontend-verden må du tenke nøye gjennom hvor og når data hentes.Du kan hente alt på serversiden, alt på klientsiden, eller bruke en hybrid. Hvert valg påvirker mellomlagringsstrategier, tid til interaksjon og opplevd hastighet.
Serversiden inkluderer naturlig oppmuntring til henting per fragment på serversidenHver mikrofrontend kommuniserer med «sine» backend-tjenester, gjengir HTML og returnerer den til skallet. Denne HTML-en kan mellomlagres uavhengig av andre fragmenter, noe som bidrar til å skalere deler med mye trafikk, som innlogging eller produktlister.
Når du laster inn data på klienten, bør du budsjettere for progressive tilstander: initialt skjelett, raske oppdateringer når attributter endres, og reserve-atferd når API-er er trege. Noen ganger er det mindre visuelt forstyrrende å holde gamle data på plass til nye data kommer enn å vise et skjelett for hver mindre endring.
Mikrofrontender med React
React er et veldig populært valg for implementering av mikrofrontender på grunn av økosystemet og renderingsoptimaliseringene.Den virtuelle DOM-en og diffingen gjør det enkelt å oppdatere små deler av brukergrensesnittet basert på prop-endringer eller global tilstand, og du kan pakke React-apper enten som frittstående SPA-er eller som tilpassede elementer.
Migrering mellom React-versjoner pleier å være trinnvis og relativt smertefri. sammenlignet med noen andre rammeverk, noe som er nyttig når mange uavhengige team vedlikeholder separate mikrofrontender. Du trenger ikke at alle fragmentene hopper fra én hovedversjon til en annen samtidig.
Baksiden er at desentraliserte React-mikrofrontender kan skape ressursspredning.Flere team, flere CI/CD-pipelines, mange pakker, mange små repositorier. Uten nok automatisering for bygging, provisjonering og observerbarhet blir denne overheaden vanskelig å håndtere.
Et annet praktisk problem er buntstørrelsenHvis hver mikrofrontend sender sin egen kopi av React og delte biblioteker, kan den totale nedlastingsstørrelsen eksplodere, spesielt når flere fragmenter er nødvendige for å gjengi en side. Løsninger som Module Federation (for å dele avhengigheter under kjøring) eller en sterkt justert stakk på tvers av team kan redusere dette.
Mikrogrensesnitt med Angular
Angular egner seg fint til mer egenrådige mikrofrontend-oppsett, spesielt når du bruker monorepos og verktøyene rundt dem (som Nx). Angular-arbeidsområder er organisert i prosjekter og biblioteker, noe som gjør det naturlig å dele en stor løsning inn i flere apper og delte biblioteker.
Siden Angular 12 og Webpack 5 har Module Federation blitt en førsteklasses borgerEt Angular-prosjekt kan konfigureres som en vert eller en fjernkontroll ved hjelp av skjematiske kommandoer, og koble til de nødvendige webpack.config.js og bootstrap-logikk for deg.
I denne modellen fungerer «verts»-Angular-appen som skallet som orkestrerer navigasjon, delt tilstand og avhengighetsdeling. Individuelle Angular-mikrofrontender (fjernkontroller) eksponerer Angular-moduler som verten kan lazyloade dynamisk via Module Federation.
De vanlige Angular-rutingsprimitivene gjelder fortsattInnenfor en mikrogrensesnitt bruker du RouterModule.forChild for definisjoner av underruter, slik at verten er den eneste som bruker forRootPå den måten kan flere Angular-apper sameksistere under et enhetlig URL-område uten ruterkonflikter.
Modulføderasjon i praksis (Angular-eksempel)
Webpack Module Federation er en Webpack 5-funksjon som lar flere bygg dele kode under kjøring.Én bygging (verten) laster dynamisk inn moduler som eksponeres av andre bygginger (fjernkontroller) via en liten manifestfil, vanligvis kalt remoteEntry.js.
I Angular kan du stille dette ganske rasktDu kan for eksempel opprette en vertsapp (host-app) og kjør deretter et skjema som ng add @angular-architects/module-federation --project host-app --port 4200Dette setter opp en ModuleFederationPlugin-konfigurasjon, oppstartsfiler og kjøretidslogikk.
Deretter oppretter du to eksterne Angular-apper: én for en produktkatalog og én for en handlekurvHver app får sin egen port (f.eks. 4201 for products-app, 4202 for cart-app) og sin egen modulføderasjonskonfigurasjon. I webpack.config.js av hver fjernkontroll du bruker exposes å publisere en modul (vanligvis hovedmodulen i appen) under en nøkkel som ./ProductsModule or ./CartModule.
Vertsskallet definerer deretter ruter som laster inn disse eksterne modulene sakte. av loadRemoteModule fra @angular-architects/module-federationFor eksempel å navigere til /products utløser en dynamisk import fra http://localhost:4201/remoteEntry.js og laster ProductsModule; /cart gjør det samme med handlevognens fjernkontroll.
Inne i katalogens mikrogrensesnitt kan det hende du har en ProductsComponent som gjengir en tabell med elementer, leser data fra en PRODUCTS_CATALOG konstant og tilbyr en «Legg til i handlekurven»-knapp. Ved klikk lagres varen i localStorage under en «handlekurv»-tast, som øker mengdene når produktet allerede finnes.
Handlekurvens mikrogrensesnitt leser deretter fra det samme localStorage nøkkel, viser en tabell med produktnavn, pris, antall og totalsum, og tilbyr en «Tøm handlekurv»-knapp som sletter lagringsplassen og tilbakestiller den interne tilstanden. Dette er en enkel, men illustrerende måte å dele tilstand på tvers av to uavhengige apper uten tett kobling.
Bygge vertsskallet: layout, hjem og navigasjon
Et solid vertsskall er avgjørende for en god brukeropplevelse på tvers av mikrogrensesnittDen eier vanligvis det globale oppsettet (topptekst, bunntekst, sidefelt), ruting på toppnivå og noen ganger global tilstand som autentisering eller funksjonsflagg.
I Angular-eksemplet definerer verten en LayoutComponent som gjengir en header og en nestet router-outletToppteksten lever i sin egen HeaderModule og eksponerer navigasjonslenker til hjemmesiden, produktlisten og handlekurven via Angulars routerLinkRutebaner kan sentraliseres i en enum som RoutesPath for å unngå magiske strenger.
Layoutrutingsmodulen setter opp en overordnet rute med LayoutComponent som sin komponent og definerer underruter for /home, /products og /cart. De /home banen laster inn en lokal HomeModule; de andre bruker loadRemoteModule å trekke inn Angular-mikrofrontendene under kjøretid.
Innenfor verten, en SharedModule kan samle gjenbrukbare byggeklosser som header, layout, vanlige direktiver og konstanter. Denne modulen kan importeres til roten AppModule samt AppRoutingModule, som peker den tomme banen til konfigurasjonen for layoutruting.
Next.js og mikrogrensesnitt
Next.js, som React-rammeverket i produksjonsklassen, fungerer også godt med en mikrofrontend-tilnærming., spesielt siden den tok i bruk Webpack 5 og dermed støtte for Module Federation. Fokuset på SSR, trinnvis statisk regenerering og ruting gjør den til en god kandidat for skallet, individuelle mikrofrontender eller begge deler.
For å implementere mikrofrontender i Next.js konfigurerer du vanligvis Module Federation på Webpack-nivå., eksponere visse sider eller komponenter som eksterne enheter og konsumere dem fra en vert. Selv om Module Federation «bare» er en JavaScript-pakkefunksjon, kan du tenke på det som et arkitektonisk mønster: det lar deg dynamisk laste inn kode som eies av forskjellige team uten å pakke alt sammen på forhånd.
For eldre Next.js-versjoner uten Webpack 5 trenger du eksterne adaptere. for å aktivere støtte for føderasjon. Fra Next 10.2 og utover er Webpack 5-støtte innebygd, noe som forenkler oppsettet dramatisk.
Single-SPA og andre mikrofrontend-rammeverk
Single-SPA er en annen velkjent løsning for mikrofrontender, spesielt i React-økosystemer.Den fokuserer på å orkestrere flere uavhengige apper på samme side, hver montert i sin egen DOM-node basert på gjeldende rute.
Med Single-SPA kan du ha flere React-applikasjoner (eller til og med blande React, Vue og Angular) samtidig.Rammeverket håndterer når hver mikrofrontend skal bootstrappes, monteres eller avmonteres mens brukeren navigerer, og du kobler det til rutingsstrategien din (for eksempel med React Router i hvert fragment).
Når du velger mellom Single-SPA og Module Federation, vurderer team ofte sine preferanser for buntering/verktøy. Modulføderasjon integreres dypt med Webpack (og i økende grad med alternativer som Rspack eller Rollup etter hvert som de legger til støtte). Single-SPA, derimot, handler mer om runtime-orkestrering enn buntdeling, slik at du kan bruke det med forskjellige byggeverktøy samtidig som du håndterer kodedeling på andre måter.
Mål, funksjoner og fordeler med mikrofrontender
Hovedmålet med mikrofrontender er å skalere frontend-utvikling på tvers av mange team uten å kollapse under koordineringskostnader.I stedet for én gigantisk kodebase med synkroniserte utgivelser, får du mindre, uavhengig utplasserbare enheter.
Viktige mål inkluderer vanligvis slik at flere team kan jobbe parallelt, støtte uavhengig distribusjon for ulike deler av brukergrensesnittet, opprettholde fleksibilitet til å bruke ulike teknologier der det gir mening og forbedre vedlikeholdbarheten ved å redusere størrelsen og kompleksiteten til hver kodebase.
Typiske kjennetegn ved en slik arkitektur er gjenbruk av komponenter gjennom delte biblioteker, modulær integrasjon via et applikasjonsskall, uavhengige pipelines per mikrofrontend, ytelsesoptimalisering via CDN-er og mellomlagring, sentralisert sikkerhetshåndtering og sterk observerbarhet.
Fra et forretningsperspektiv er fordelene betydeligeUtvikling skaleres bedre med flere team, feil isoleres bedre, funksjoner kan rulles ut eller tilbake per domene, og eldre frontend-stabler kan migreres gradvis ved å erstatte én skive om gangen i stedet for å skrive om hele appen.
Nøkkelkomponenter i en mikrofrontend-arkitektur
Selv om implementeringene varierer, deler de fleste mikrofrontend-arkitekturer noen få strukturelle komponenter. som holder alt sammenhengende.
Applikasjonsskallet (eller containeren) er ryggradenDen eier det ytre oppsettet, den globale navigasjonen, autentiseringen, noen ganger den globale tilstanden, og logikken for lasting eller lossing av mikrogrensesnitt. I nettleserbaserte oppsett er det siden som henter inn alle andre bunter.
Hver mikrofrontend er en selvstendig modul som implementerer en spesifikk funksjonalitet, for eksempel produktkatalog, handlekurv, brukerprofil eller administrasjonspanel. Den eksponerer en integrasjonsflate (ruter, tilpassede elementer, modulføderasjonsfjernkontroller) og skjuler interne detaljer fra resten av systemet.
En hendelsesbuss eller et meldingssystem er ofte til stede for kommunikasjon på tvers av mikrofrontendDette kan være en enkel abstraksjon over DOM-hendelser, en sentralisert Redux-butikk eller en tilpasset meldingsmegler. Målet er frakoblet publiser/abonner-semantikk: en mikrofrontend sender ut hendelser uten å vite hvem som håndterer dem.
Delte biblioteker er vert for gjenbrukbare UI-komponenter, verktøy, designtokener og felles klienterI monorepo-oppsett skinner verktøy som Nx her, og lar deg definere delte pakker som forbrukes av flere apper med håndhevede grenser og konsistente versjoner.
Observasjonssamlere og verktøy (for eksempel ved bruk av OpenTelemetry) samle logger, beregninger og spor fra alle mikrogrensesnitt, noe som gjør det mulig å diagnostisere problemer som strekker seg over flere fragmenter eller tjenester.
CDN-er fullfører bildet på leveringssiden, mellomlagrer statiske ressurser som JS-pakker, CSS og bilder nær brukerne, reduserer latens og avlaster opprinnelsesservere. I mikrofrontend-oppsett er du ofte vert for hvert fragments ressurser på sin egen CDN-bane for uavhengig mellomlagring og utrulling.
Arkitektur- og designmønstre for mikrofrontender
Det finnes en rikholdig katalog med mønstre som gjelder spesifikt for mikrofrontender., vanligvis definert av hvordan du komponerer, distribuerer og kobler dem til.
Komponentbasert komposisjon betyr å bygge brukergrensesnittet ut av webkomponenter eller lignende primitiverHver komponent har ett enkelt ansvar, tydelige input og output, og kan testes isolert. Et komposisjonslag på et høyere nivå (som et skall eller et orkestreringsrammeverk) arrangerer disse komponentene til fulle sider.
Føderasjonsmønsteret vektlegger fullstendig applikasjonsautonomiHver mikrofrontend er en frittstående app med sin egen livssyklus og team; skallet eller en API-gateway ruter ganske enkelt forespørsler/data til riktig fragment. Kommunikasjon skjer gjennom veldefinerte REST API-er eller hendelser.
Applikasjonsskallmønsteret er effektivt sett «vert»-tilnærmingenSkallet laster inn mikrogrensesnitt, håndterer tverrgående bekymringer som navigasjon og sikkerhet, og sikrer et konsistent utseende og preg. Dette er veldig vanlig med modulføderasjon eller oppsett basert på ett SPA.
API-gateway og Backend-for-Frontend (BFF)-mønstre fokuserer på serversidenEn API-gateway sitter foran mange backend-tjenester, ruter forespørsler og bruker sikkerhet. En BFF går lenger: hver frontend (web, mobil, IoT) kan få sin egen dedikerte backend skreddersydd til sine behov.
Distribuerte datalagringsmønstre erkjenner at forskjellige mikrofrontender kan administrere sine egne datakilder eller hurtigbuffere. I nettleseren betyr dette ofte bruk av separate localStorage-nøkler, IndexedDB-databaser eller minnelagre, mens det på backend betyr separate databaser per mikrotjeneste.
Observerbarhet, uavhengig distribusjon, horisontal skalerbarhet og sikkerhetsmønstre adressere driftsmessige bekymringer: hvordan overvåke hvert fragment, hvordan distribuere dem uten globale avbrudd, hvordan skalere dem under belastning og hvordan håndheve autentisering/autorisasjon konsekvent.
Rutekomposisjon og late lastemønstre er sentralt for UX og ytelseEn masterruter bestemmer hvilken mikrofrontend som håndterer hvilken sti, og hver mikrofrontend har sin egen interne ruter. Lazy loading sikrer at du bare laster ned koden for fragmentene som faktisk trengs for den gjeldende ruten.
Til slutt sikrer hendelsesbaserte kommunikasjonsmønstre at løst koblede mikrofrontender fortsatt kan koordinere gjennom domenehendelser, uten å introdusere direkte avhengigheter som ville omgå poenget med modularitet.
Når man skal bruke mikrofrontender (og når ikke)
Mikrofrontender skinner i store, komplekse applikasjoner med veldefinerte funksjonelle domenerTenk e-handelsplattformer, bedriftsstyringssystemer, kommunale portaler, utdanningsplattformer, store helseportaler eller et hvilket som helst produkt med mange team som jobber med separate funksjonsområder.
De er spesielt nyttige når du har flere team som jobber parallelt som trenger autonomi i teknologiske valg, utgivelsessykluser og prioriteringer, eller når du sakte moderniserer et eldre frontend og ikke har råd til en fullstendig omskriving. Du kan skjære ut ett område om gangen til en ny mikrofrontend og integrere den med det gamle skallet.
De hjelper også når ulike deler av appen må skaleres forskjellig.En innloggings- eller betalingsside kan få mye mer trafikk enn en administratorkonfigurasjonsskjerm. Å skalere disse sektorene uavhengig kan spare mye infrastrukturkostnader.
Mikrofrontender er imidlertid ikke en gratis lunsj.De tilfører arkitektonisk kompleksitet, krever sterk koordinering av brukeropplevelse og delte kontrakter, og introduserer nye feilmoduser (for eksempel at ett fragment ikke lastes inn). For små eller mellomstore apper med ett enkelt team er en velstrukturert monolitt ofte enklere og mer kostnadseffektiv.
Lag bør også være forsiktige med «rammeverksanarki»Selv om det er teknisk mulig for hver mikrofrontend å bruke en helt annen stabel, gjør en ukontrollert blanding av rammeverk ansettelse, verktøy og kodedeling vanskeligere. Et rimelig nivå av samsvar (for eksempel «vi er en React-first-butikk, men vi tillater Angular for spesifikke domener») fungerer vanligvis bedre i det lange løp.
Mikrofrontender utvider mikrotjenestetankegangen til nettleseren, og gir team en måte å dele opp store frontender i autonome, domeneorienterte deler som kan utvikles, distribueres og skaleres uavhengig, samtidig som de danner en helhetlig brukeropplevelse når de kombineres gjennom et applikasjonsskall, delte biblioteker, modulføderasjon, webkomponenter eller orkestreringsrammeverk som Single-SPA.
