Hvordan mikrofrontends fungerer: Arkitektur, mønstre og eksempler

Hjem » Python » Hvordan mikrofrontends fungerer: Arkitektur, mønstre og eksempler

Mikrofrontends er blevet et af de mest omtalte frontend-arkitekturmønstre. for teams, der voksede fra den klassiske enkeltsidede monolit. Når du har snesevis af udviklere, der berører den samme kodebase, bliver udgivelsescyklusser langsommere, regressioner sniger sig ind overalt, og små ændringer i brugergrænsefladen kræver pludselig massiv koordinering. Mikrofrontends angriber præcis dette problem ved at opdele brugergrænsefladen i uafhængigt byggede og implementerede dele.

I denne guide vil vi gennemgå, hvad mikrofrontender er, hvorfor de opstod, og hvordan de relaterer sig til mikrotjenester., hvilke kerneideer 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 virkelige arkitekturmønstre, god praksis, almindelige faldgruber og konkrete eksempler som et produktkatalog og en indkøbskurv implementeret som separate microfrontends.

Hvad er mikrofrontender, og hvorfor opstod de?

Udtrykket "mikro-frontends" blev populariseret omkring 2016 i ThoughtWorks Technology Radar som et svar på en meget konkret tendens: backend-arkitekturer bevægede sig mod mikrotjenester, men browsersiden forblev en stor, skrøbelig monolit ejet af et enkelt team. Med tiden bliver det "fede klient"-SPA svært at udvikle, selvom backend'en er pænt opdelt i små tjenester.

En mikrofrontend er i bund og grund den mikroservice-ide, der anvendes på browserens brugergrænseflade.I stedet for ét stort frontend-lager, sammensætter du brugergrænsefladen af ​​flere mindre, selvstændige applikationer. Hver applikation ejer et klart forretningsdomæne (f.eks. "kasse", "produktsøgning", "studerendeprofiler") og kan bygges, testes og implementeres i sin egen takt.

Ligesom mikrotjenester opdeler backend-logik i separate, udrullelige enheder, opdeler mikrofrontends frontend i lodrette skiver. der spænder fra databasen eller API'erne, gennem backend og op til brugergrænsefladen. Et tværfunktionelt team ejer det vertikale udsnit fra start til slut, fra dataskema til brugergrænsefladekomponenter.

Denne "vertikale organisation" står i kontrast til en horisontal opdeling i lag (et team til brugergrænsefladen, et andet til API'erne, et andet til databasen). Vertikale teams har en tendens til at levere hurtigere, fordi de ikke behøver at koordinere hver eneste lille ændring på tværs af halvdelen af ​​virksomheden.

Fra et applikationssynspunkt er en microfrontend en autonom webapplikation der kan sammensættes til en større oplevelse: den kan have sin egen routing, tilstandsstyring, designsystem og implementeringspipeline, så længe den respekterer et sæt kontrakter med resten af ​​systemet (URL'er, begivenheder, API'er, delte biblioteker osv.).

Kerneideer og principper bag mikrofrontends

Flere tilbagevendende principper optræder i succesfulde microfrontend-arkitekturerDet er ikke strenge regler, men de vil spare dig for en masse smerte, hvis du bruger dem som rækværk.

Teknologiagnosticisme er et af de mest berømte principper: hvert team skal kunne vælge og opgradere sin teknologistak uden at synkronisere med alle andre. Måske er én mikrofrontend på React, en anden i Angular og en ældre i Vue. Browser-native abstraktioner som Custom Elements (Web Components) hjælper med at skjule disse forskelle bag en standard DOM API.

Stærk isolation mellem teamkodebaser er et andet vigtigt målIdeelt set deler mikrofrontends ikke en JavaScript-runtime eller globale variabler. Hvert bundt er selvstændigt, indlæser sine egne afhængigheder og er ikke afhængig af skjult tilstand fra andre. Det reducerer utilsigtet kobling og gør uafhængige implementeringer meget mere realistiske.

For at undgå navnekonflikter bliver teams ofte enige om eksplicitte navnerum. til CSS-klasser, DOM-begivenheder, localStorage-nøgler, cookies eller endda brugerdefinerede element-tagnavne. For eksempel kan et checkout-team præfiksere ting med chk- eller brug et tag som <blue-buy>, mens et anbefalingsteam bruger rec- or <green-recos>DOM viser dig med et enkelt blik, hvem der ejer hvilket stykke.

Et andet princip er at foretrække native browserfunktioner frem for brugerdefinerede globale API'erI stedet for at opfinde et all-purpose PubSub-system, kan du stole på standard DOM-hændelser, CustomEvent, historik-API til routing eller selve DOM'en som integrationslag. Når du virkelig har brug for en delt API, så hold den så lille og stabil som muligt.

Endelig bør robusthed være en del af designet fra dag étHver mikrofrontend bør stadig levere en vis værdi, når JavaScript er langsomt, fejler eller er blokeret. Teknikker som server-side rendering, progressiv forbedring og skeletskærme hjælper med at holde den oplevede ydeevne høj, selv under dårlige netværksforhold.

Hvad er en "moderne webapplikation" i denne sammenhæng?

Ikke alle hjemmesider har brug for mikrofrontends eller en kompleks browserintegrationsstrategiEn god mental model kommer fra "dokumenter-til-applikationer-kontinuumet": til venstre har du for det meste statiske dokumenter, der er knyttet sammen; til højre har du fuldt interaktive apps som et online billedredigeringsprogram.

Hvis dit projekt er mere statiske dokumenter, er en simpel server-renderet komposition ofte nok.Serveren samler HTML-fragmenter fra forskellige kilder, samler dem og sender dem til browseren. Opdateringer sker via indlæsning af hele sider eller små Ajax-injektioner, og det er helt fint.

Når du bevæger dig mod mere dynamiske, app-lignende oplevelser—øjeblikkelig feedback, offline arbejde, optimistiske brugergrænsefladeopdateringer — ren serversideintegration er ikke længere tilstrækkelig. Du har brug for klientsidekomposition, tilstandsstyring og routing. Det er her, mikrofrontends bliver interessante: de giver dig en måde at skalere den kompleksitet på tværs af mange teams.

Vertikal organisering og domænedrevne skiver

En almindelig anbefaling er at tilpasse mikrofrontends til forretningsdomæner i stedet for tekniske lag.Tænk i brugerrejser: "indkøbskurv", "produktoplysninger", "administratorbrugere", "kursusskemaer", "studenterregistreringer", "fakturaer" osv.

Hvert af disse domæner kan blive sin egen mikrofrontend med et veldefineret ansvarI et universitetssystem kan én app administrere studenterprofiler, en anden medarbejderprofiler, en tredje kursusplaner og en anden brugergrænsefladen til eksamensresultater. De deler en shell og måske noget styling, men hver især er de en uafhængig applikation set fra et implementeringsperspektiv.

God slicing tager også højde for begrænsede kontekster for dine backend-mikrotjenester.Ideelt set kommunikerer mikrofrontend'en til "fakturering" primært med faktureringsmikrotjenesterne, "katalog"-frontend'en kommunikerer med katalogtjenesterne osv. Det holder hvert vertikalt segment sammenhængende og reducerer afhængigheder på tværs af teams.

Teknisk integration: DOM som API og webkomponenter

I browser-sidede mikrofrontend-arkitekturer fungerer DOM'en ofte som den primære integrations-API.I stedet for at kalde hinandens JavaScript direkte, eksponerer teams funktionalitet gennem HTML-elementer, attributter og hændelser.

Brugerdefinerede elementer (en del af webkomponenter) er et effektivt primitiver til dette formål.Et team kan bygge en funktion ved hjælp af et hvilket som helst framework, det ønsker, og derefter pakke den ind som et brugerdefineret tag, for eksempel <order-minicart></order-minicart>Den offentlige kontrakt for den pågældende komponent er defineret af dens tagnavn, attributter og udsendte hændelser, ikke af dens interne implementering.

Browserunderstøttelse af Custom Elements v1 er nu solid på tværs af alle større browsere, hvilket betyder, at du sjældent har brug for polyfills. De fleste almindelige frameworks – React, Vue, Angular, Svelte, Preact – kan gengive eller integrere brugerdefinerede elementer, som om de var almindelige HTML-tags, og mange af dem kan også selv kompileres til et brugerdefineret element.

Integrationsmønsteret ser nogenlunde sådan udEn mikrofrontend på "produktside" bestemmer, hvilke funktioner der vises på siden (vælgere, købsknapper, minikurv, anbefalinger). Den indsætter brugerdefinerede elementer såsom <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>De hold, der ejer disse funktioner, registrerer deres elementer hos customElements.define og implementere livscyklus-tilbagekald som connectedCallback or attributeChangedCallback.

Når en produktvariant ændres, kan siden enten genskabe elementet eller blot opdatere dets attributter.Hvis komponenten observerer relevante attributter, kan den gengive sig selv igen. Internt kan komponenten bruge skabelonstrenge, React, Vue eller en hvilken som helst renderingmotor; integratoren behøver ikke at bekymre sig om det.

Klientsidekommunikation: hændelser og DOM-relationer

Overførsel af attributter fungerer godt til envejs-"data ind"-scenarier, men mange virkelige interaktioner kræver, at komponenter kommunikerer tilbage til deres omgivelser eller til søskende. Et typisk eksempel er en "køb"-knap, der skal give miniindkøbskurven besked, når en vare tilføjes.

I stedet for at bygge en brugerdefineret global eventbus, kan du læne dig op ad browserbegivenhederForsendelse af komponenter CustomEvent instanser, der bobler op gennem DOM-træet. Et overordnet element eller endda window kan lytte efter disse begivenheder og orkestrere reaktioner.

For eksempel kan købsknappen udsende en hændelse som blue:basket:changed med den aktuelle vognnyttelastMinivognen abonnerer på den begivenhed den window eller på et delt containerelement og opdaterer dets interne tilstand, hver gang det aktiveres.

Denne tilgang holder komponenterne uafhængigeKøbsknappen aner ikke, hvem, om nogen, der lytter efter dens begivenheder. Den opfylder blot sin kontrakt. Og mini-indkøbskurven afhænger kun af begivenhedens semantik, ikke af implementeringsdetaljerne for andre fragmenter.

Serverside-rendering og universelle komponenter

Hvis du er interesseret i førstegangsoptimering, SEO eller robusthed, når JavaScript fejler, er server-side rendering (SSR) afgørende.Rene klientsidede webkomponenter vises kun efter JS-bundtet er downloadet og kørt, hvilket kan betyde en hvid skærm på langsomme netværk.

En pragmatisk løsning er at kombinere brugerdefinerede elementer med server-side includes (SSI/ESI).Hver mikrofrontend eksponerer et HTTP-slutpunkt, der returnerer HTML'en for dens fragment, for eksempel /blue-buy?sku=t_porscheHovedsiden, gengivet af en shell- eller værtsapplikation, indeholder pladsholdere som f.eks. <!--#include virtual="/blue-buy?sku=t_porsche" --> som webserveren (ofte nginx) udvider, før den sender svaret til browseren.

Ved kørsel i browseren hydreres eller geninitialiseres det samme brugerdefinerede element når dens JS-bundle er indlæst. Det giver dig en "universel" komponent: den kan gengives på serveren for hastighed og SEO, og derefter opføre sig som et fuldt interaktivt brugerdefineret element på klienten.

En ulempe ved SSR med includes er, at det langsomste fragment dikterer den samlede responstidCachelagring på fragmentniveau er næsten obligatorisk. For dyre, meget personlige stykker (som anbefalinger) kan du springe server-side rendering over og indlæse dem asynkront på klienten.

Skeletonskærme er et godt kompromis for at undgå forstyrrende layoutskiftEt fragment kan server-rendere en gråtonet pladsholder med omtrent samme størrelse som det endelige indhold. Når de faktiske data ankommer på klientsiden, udskiftes skelettet uden store reflows.

Dataindlæsning og opfattet ydeevne

I en microfrontend-verden skal man tænke grundigt over, hvor og hvornår data hentes.Du kan hente alt på serversiden, alt på klientsiden eller bruge en hybrid. Hvert valg påvirker cachingstrategier, tid til interaktion og opfattet hastighed.

Serversiden inkluderer naturligt opmuntring til serversidehentninger pr. fragmentHver mikrofrontend kommunikerer med "sine" backend-tjenester, gengiver HTML og returnerer den til skallen. Denne HTML kan caches uafhængigt af andre fragmenter, hvilket hjælper med at skalere dele med høj trafik som login eller produktlister.

Når du indlæser data på klienten, bør du budgettere med progressive tilstande: initialt skelet, hurtige opdateringer når attributter ændres, og fallback-adfærd når API'er er langsomme. Nogle gange er det mindre visuelt forstyrrende at holde gamle data på plads, indtil der kommer nye data, end at vise et skelet for hver mindre ændring.

Mikrofrontends med React

React er et meget populært valg til implementering af microfrontends på grund af dets økosystem og renderingsoptimeringer.Den virtuelle DOM og diffing gør det nemt at opdatere små dele af brugergrænsefladen baseret på propændringer eller global tilstand, og du kan samle React-apps enten som separate SPA'er eller som brugerdefinerede elementer.

Migrering mellem React-versioner er typisk trinvis og relativt smertefri sammenlignet med nogle andre frameworks, hvilket er nyttigt, når mange uafhængige teams vedligeholder separate mikrofrontends. Du behøver ikke, at alle fragmenter hopper fra én overordnet version til en anden på samme tid.

Bagsiden er, at decentraliserede React-mikrofrontends kan skabe ressourcespredningFlere teams, flere CI/CD-pipelines, mange bundter, mange små repos. Uden tilstrækkelig automatisering til build, provisionering og observerbarhed bliver det overhead svært at håndtere.

Et andet praktisk problem er bundtstørrelsenHvis hver mikrofrontend leverer sin egen kopi af React og delte biblioteker, kan den samlede downloadstørrelse eksplodere, især når der er behov for flere fragmenter for at gengive en side. Løsninger som Module Federation (til at dele afhængigheder under kørsel) eller en stærkt justeret stak på tværs af teams kan afbøde dette.

Mikrofrontender med Angular

Angular egner sig godt til mere opinionsbaserede microfrontend-opsætninger, især når du bruger monorepos og værktøjerne omkring dem (som Nx). Angular-arbejdsområder er organiseret i projekter og biblioteker, hvilket gør det naturligt at opdele en stor løsning i flere apps og delte biblioteker.

Siden Angular 12 og Webpack 5 er Module Federation blevet en førsteklasses borgerEt Angular-projekt kan konfigureres som en vært eller en fjernbetjening ved hjælp af skematiske kommandoer, der forbinder de nødvendige webpack.config.js og bootstrap-logik for dig.

I denne model fungerer "værten" af Angular-appen som shell der orkestrerer navigation, delt tilstand og afhængighedsdeling. Individuelle Angular-mikrofrontender (fjernbetjeninger) eksponerer Angular-moduler, som værten kan lazy-loade dynamisk via Module Federation.

De sædvanlige Angular-routingprimitiver gælder stadigInden for en mikrofrontend bruger du RouterModule.forChild for definitioner af underordnede ruter, så værten er den eneste, der bruger forRootPå den måde kan flere Angular-apps sameksistere under et samlet URL-rum uden routerkonflikter.

Modulføderation i praksis (Angular-eksempel)

Webpack Module Federation er en Webpack 5-funktion, der tillader flere builds at dele kode under kørsel.En build (værten) indlæser dynamisk moduler, der er eksponeret af andre builds (fjernenheder) via en lille manifestfil, typisk kaldet remoteEntry.js.

I Angular kan du scaffolde dette ret hurtigtFor eksempel kan du oprette en værtsapp (host-app) og kør derefter et diagram som ng add @angular-architects/module-federation --project host-app --port 4200Dette opsætter en ModuleFederationPlugin-konfiguration, bootstrapping-filer og runtime-logik.

Derefter opretter du to eksterne Angular-apps: én til et produktkatalog og én til en indkøbskurvHver app får sin egen port (f.eks. 4201 for products-app, 4202 for cart-app) og dens egen modulføderationskonfiguration. I webpack.config.js af hver fjernbetjening, du bruger exposes at udgive et modul (typisk det primære appmodul) under en nøgle som ./ProductsModule or ./CartModule.

Værtsskallen definerer derefter ruter, der langsomt indlæser disse fjernmoduler. via loadRemoteModule fra @angular-architects/module-federationFor eksempel at navigere til /products udløser en dynamisk import fra http://localhost:4201/remoteEntry.js og belastninger ProductsModule; /cart gør det samme med vognens fjernbetjening.

Inde i katalogets mikrofrontend har du muligvis en ProductsComponent der gengiver en tabel over elementer, læser data fra en PRODUCTS_CATALOG konstant og tilbyder en "Tilføj til kurv"-knap. Ved klik bevares varen i localStorage under en "indkøbskurv"-tast, der øger mængderne, når produktet allerede findes.

Indkøbskurvens mikrofrontend læser derefter fra det samme localStorage nøgle, viser en tabel med produktnavn, pris, antal og total, og tilbyder en "Ryd indkøbskurv"-knap, der sletter lagerpladsen og nulstiller dens interne tilstand. Dette er en simpel, men illustrativ måde at dele tilstand på tværs af to uafhængige apps uden tæt kobling.

Opbygning af værtsskallen: layout, startside og navigation

En solid værtskal er afgørende for en god brugeroplevelse på tværs af mikrofrontenderDen ejer normalt det globale layout (header, footer, sidebjælker), routing på topniveau og sommetider globale tilstande som godkendelse eller funktionsflag.

I Angular-eksemplet definerer værten en LayoutComponent der gengiver en header og en indlejret router-outlet. Overskriften lever i sin egen HeaderModule og viser navigationslinks til startsiden, produktlisten og indkøbskurven via Angulars routerLinkRutestier kan centraliseres i en enum som f.eks. RoutesPath for at undgå magiske strenge.

Layout-rutemodulet opretter en overordnet rute med LayoutComponent som sin komponent og definerer underordnede ruter for /home, /products og /cart. Det /home sti indlæser en lokal HomeModule; de andre bruger loadRemoteModule at trække Angular-mikrofrontenderne ind under kørsel.

Inden for værten, en SharedModule kan samle genbrugelige byggeklodser som header, layout, fælles direktiver og konstanter. Dette modul kan importeres til roden AppModule sammen med AppRoutingModule, som peger den tomme sti til layoutroutingkonfigurationen.

Next.js og mikrofrontends

Next.js, som React-frameworket i produktionsklassen, fungerer også godt sammen med en microfrontend-tilgang., især da den implementerede Webpack 5 og dermed Module Federation-understøttelse. Dens fokus på SSR, trinvis statisk regenerering og routing gør den til en god kandidat til shell, individuelle mikrofrontends eller begge dele.

For at implementere microfrontends i Next.js konfigurerer du typisk Module Federation på Webpack-niveau., eksponere bestemte sider eller komponenter som fjerntliggende enheder og forbruge dem fra en vært. Selvom Module Federation "bare" er en JavaScript-bundlerfunktion, kan du tænke på det som et arkitektonisk mønster: det giver dig mulighed for dynamisk at indlæse kode, der ejes af forskellige teams, uden at samle alt på forhånd.

For ældre Next.js-versioner uden Webpack 5 skal du bruge eksterne adaptere. for at aktivere understøttelse af føderation. Fra Next 10.2 og fremefter er Webpack 5-understøttelse indbygget, hvilket forenkler opsætningen dramatisk.

Single-SPA og andre microfrontend-frameworks

Single-SPA er en anden velkendt løsning til microfrontends, især i React-økosystemer.Det fokuserer på at orkestrere flere uafhængige apps på den samme side, der hver især er monteret på sin egen DOM-node baseret på den aktuelle rute.

Med Single-SPA kan du have flere React-applikationer (eller endda blande React, Vue og Angular) samtidigFrameworket håndterer, hvornår hver microfrontend skal bootstrappes, monteres eller afmonteres, mens brugeren navigerer, og du integrerer det i din routingstrategi (for eksempel med React Router i hvert fragment).

Når du vælger mellem Single-SPA og Module Federation, teams overvejer ofte deres præferencer for bundlere/værktøjer. Modulføderation integreres dybt med Webpack (og i stigende grad med alternativer som Rspack eller Rollup, efterhånden som de tilføjer understøttelse). Single-SPA handler derimod mere om runtime-orkestrering end bundtdeling, så du kan bruge det med forskellige byggeværktøjer, mens du håndterer kodedeling på andre måder.

Mål, funktioner og fordele ved mikrofrontends

Hovedformålet med mikrofrontends er at skalere frontend-udvikling på tværs af mange teams uden at kollapse under koordineringsomkostninger.I stedet for én kæmpe kodebase med synkroniserede udgivelser får du mindre enheder, der kan implementeres uafhængigt.

Hovedmålene omfatter normalt gør det muligt for flere teams at arbejde parallelt, understøtter uafhængig implementering for forskellige dele af brugergrænsefladen, opretholder fleksibilitet til at bruge forskellige teknologier, hvor det giver mening, og forbedrer vedligeholdelsen ved at reducere størrelsen og kompleksiteten af ​​hver kodebase.

Typiske karakteristika for en sådan arkitektur er genbrug af komponenter gennem delte biblioteker, modulær integration via en applikationsshell, uafhængige pipelines pr. microfrontend, ydeevneoptimering via CDN'er og caching, centraliseret sikkerhedshåndtering og stærk observerbarhed.

Fra et forretningsperspektiv er fordelene betydeligeUdvikling skaleres bedre med flere teams, fejl isoleres bedre, funktioner kan udrulles eller rulles tilbage pr. domæne, og ældre frontend-stakke kan migreres gradvist ved at udskifte ét slice ad gangen i stedet for at omskrive hele appen.

Nøglekomponenter i en microfrontend-arkitektur

Selvom implementeringer varierer, deler de fleste mikrofrontend-arkitekturer et par strukturelle komponenter. der holder alting sammenhængende.

Applikationsskallen (eller containeren) er rygradenDen ejer det ydre layout, den globale navigation, godkendelse, nogle gange den globale tilstand og logikken til indlæsning eller aflæsning af mikrofrontends. I browserbaserede opsætninger er det siden, der trækker alle andre bundter ind.

Hver mikrofrontend er et selvstændigt modul, der implementerer en specifik funktion, såsom produktkatalog, indkøbskurv, brugerprofil eller administrationspanel. Det eksponerer en integrationsflade (ruter, brugerdefinerede elementer, modulføderationsfjernbetjeninger) og skjuler interne detaljer fra resten af ​​systemet.

En eventbus eller et meddelelsessystem er ofte til stede til kommunikation på tværs af mikrofrontenderDette kan være en simpel abstraktion over DOM-begivenheder, et centraliseret Redux-lager eller en brugerdefineret beskedbroker. Målet er afkoblet publicer/abonner-semantik: en mikrofrontend udsender begivenheder uden at vide, hvem der håndterer dem.

Delte biblioteker er vært for genanvendelige UI-komponenter, værktøjer, designtokens og fælles klienterI monorepo-opsætninger skinner værktøjer som Nx frem her, så du kan definere delte pakker, der forbruges af flere apps med håndhævede grænser og ensartede versioner.

Observationsindsamlere og værktøjer (for eksempel ved hjælp af OpenTelemetry) samler logfiler, metrikker og spor fra alle mikrofrontender, hvilket gør det muligt at diagnosticere problemer, der spænder over flere fragmenter eller tjenester.

CDN'er fuldender billedet på leveringssiden, cachelagring af statiske aktiver som JS-bundler, CSS og billeder tæt på brugerne, hvilket reducerer latenstid og aflaster oprindelsesservere. I microfrontend-opsætninger hoster du ofte hvert fragments aktiver på dets egen CDN-sti for uafhængig caching og udrulning.

Arkitektur- og designmønstre til mikrofrontends

Der er et rigt katalog af mønstre, der specifikt gælder for mikrofrontends., normalt defineret af, hvordan du sammensætter, implementerer og forbinder dem.

Komponentbaseret komposition betyder at bygge brugergrænsefladen ud af webkomponenter eller lignende primitiverHver komponent har et enkelt ansvar, klare input og output og kan testes isoleret. Et kompositionslag på et højere niveau (som en shell eller et orkestreringsframework) arrangerer disse komponenter i fulde sider.

Føderationsmønsteret understreger fuldstændig applikationsautonomiHver mikrofrontend er en selvstændig app med sin egen livscyklus og team; skallen eller en API-gateway dirigerer simpelthen anmodninger/data til det korrekte fragment. Kommunikation sker via veldefinerede REST API'er eller hændelser.

Applikationsskalmønsteret er effektivt "vært"-tilgangenShell'en indlæser mikrofrontends, håndterer tværgående bekymringer som navigation og sikkerhed og sikrer et ensartet udseende og funktionalitet. Dette er meget almindeligt med Module Federation- eller Single-SPA-baserede opsætninger.

API-gateway og Backend-for-Frontend (BFF)-mønstre fokuserer på serversidenEn API-gateway sidder foran mange backend-tjenester, routerer anmodninger og anvender sikkerhed. En BFF går endnu længere: hver frontend (web, mobil, IoT) kan få sin egen dedikerede backend, der er skræddersyet til dens behov.

Distribuerede datalagringsmønstre anerkender, at forskellige mikrofrontender muligvis administrerer deres egne datakilder eller cacher. I browseren betyder dette ofte brug af separate localStorage-nøgler, IndexedDB-databaser eller in-memory-lagre, mens det på backend betyder separate databaser pr. mikroservice.

Observerbarhed, uafhængig implementering, horisontal skalerbarhed og sikkerhedsmønstre adressere operationelle bekymringer: hvordan man overvåger hvert fragment, hvordan man implementerer dem uden globale afbrydelser, hvordan man skalerer dem under belastning, og hvordan man håndhæver autentificering/autorisation konsekvent.

Routingkomposition og lazy loading-mønstre er centrale for UX og ydeevneEn masterrouter bestemmer, hvilken mikrofrontend der håndterer hvilken sti, og hver mikrofrontend har sin egen interne router. Lazy loading sikrer, at du kun downloader koden for de fragmenter, der faktisk er nødvendige for den aktuelle rute.

Endelig sikrer hændelsesbaserede kommunikationsmønstre, at løst koblede mikrofrontender stadig kan koordinere. gennem domænehændelser, uden at introducere direkte afhængigheder, der ville omgå pointen med modularitet.

Hvornår skal man bruge microfrontends (og hvornår ikke)

Mikrofrontends fungerer fremragende i store, komplekse applikationer med veldefinerede funktionelle domænerTænk e-handelsplatforme, virksomhedsstyringssystemer, kommunale portaler, uddannelsesplatforme, store sundhedsportaler eller ethvert produkt med mange teams, der arbejder på separate funktionelle områder.

De er især nyttige, når du har flere teams, der arbejder parallelt der kræver autonomi i teknologiske valg, udgivelsescyklusser og prioriteter, eller når du langsomt moderniserer en ældre frontend og ikke har råd til en fuldstændig omskrivning. Du kan udforme ét område ad gangen til en ny mikrofrontend og integrere den med den gamle shell.

De hjælper også, når forskellige dele af appen skal skaleres forskelligt.En login- eller checkout-side kan få meget mere trafik end en administratorkonfigurationsskærm; separat skalering af disse skiver kan spare mange infrastrukturomkostninger.

Mikrofrontender er dog ikke en gratis frokost.De tilføjer arkitektonisk kompleksitet, kræver stærk koordinering af brugeroplevelse og delte kontrakter og introducerer nye fejltilstande (for eksempel ét fragment, der ikke indlæses). For små eller mellemstore apps med et enkelt team er en velstruktureret monolit ofte enklere og mere omkostningseffektiv.

Hold bør også være på vagt over for "rammeanarki"Selvom det er teknisk muligt for hver mikrofrontend at bruge en helt anden stak, gør en ukontrolleret blanding af frameworks ansættelse, værktøjsudvikling og kodedeling vanskeligere. Et rimeligt niveau af tilpasning (for eksempel "vi er en React-first shop, men vi tillader Angular for specifikke domæner") fungerer normalt bedre i det lange løb.

Mikrofrontends udvider mikroservicetankegangen til browseren og giver teams en måde at opdele store frontends i autonome, domæneorienterede dele, der kan udvikle sig, implementeres og skaleres uafhængigt, samtidig med at de skaber en sammenhængende brugeroplevelse, når de kombineres via en applikationsshell, delte biblioteker, modulføderation, webkomponenter eller orkestreringsframeworks som Single-SPA.