Indholdsfortegnelse[Skjule][At vise]
Ideen om mikrotjenester har fået stor opmærksomhed på det seneste, og mange firmaer bruger den til at gøre op med store, monolitiske backends.
At gå samme vej med frontend er stadig en udfordring for mange virksomheder, selvom denne distribuerede måde at konstruere serversiden af webapps på er mere eller mindre pålidelig med hensyn til forskning og eksekvering.
På grund af sin tætte afhængighed gør klientsidemonolitten det typisk vanskeligt at integrere nye funktioner, anvende nye teknologier og skalere individuelle komponenter.
Disse og andre udfordringer har fået frontend-udviklere til at undersøge brugen af mikrotjenester.
Som et resultat blev der udviklet en helt ny arkitektonisk strategi kendt som micro frontend til at skabe front-end laget af websteder og webbaserede applikationer.
Udtrykket blev brugt første gang i 2016, og siden da har det fået stor opmærksomhed for en god sag.
Denne artikel vil give en generel forståelse af, hvad mikrofrontends er, og de problemer, de adresserer. det virker, såvel som fordele og ulemper.
Introduktion til mikro front-end arkitektur
En moderne metode til frontend-udvikling kaldet mikro-frontend-arkitektur deler en webapplikation i små, selvstændige dele.
For slutbrugeren ser disse dele ud til at være én enhed, selvom de blev konstrueret uafhængigt og derefter sat sammen.
Med den forskel, at mikrofrontends vedrører klientsiden, ikke serversiden, af onlineløsninger, er rationalet bag dem identisk med det for mikrotjenester.
At lave sofistikerede webbaserede produkter giver mest mening, når du bruger en mikrofrontend-tilgang.
Mikrofrontends, i modsætning til en mere konventionel frontend-monolit, gør det muligt for mange teams at samarbejde separat om forskellige softwareprojekter.
Programmører kan skabe webapps hurtigere og med større skalerbarhed og vedligeholdelse ved hjælp af dette arkitektoniske design.
For at sige det enkelt er hver mikrofrontend kun et stykke kode for en særskilt komponent af websiden.
Disse funktioner styres af separate teams, som hver især er specialiseret i en bestemt branche eller et bestemt mål.
Monolitisk vs Microservices vs Micro frontend-arkitektur
Tænk på at flytte. Vil det være nemmere for dig at organisere alting i et antal små, ekspertmærkede kasser og flytte hver enkelt individuelt eller pakke hele personalet sammen i en enorm kasse og transportere det til et nyt sted?
Den åbenlyse løsning er der.
Denne analogi sammenligner de to forskellige webapp-arkitekturer, monolitter og mikrotjenester (også kendt som mikrofrontends).
Monolitisk arkitektur
Du kan måske huske de "gode gamle dage", hvor en komplet ansøgning blev oprettet som en enkelt sammenhængende enhed. Sådan en metode kaldes en monolit, som er en gammel betegnelse for en stor stenblok.
Dette giver mening.
Monolitiske systemer har indbyrdes afhængige elementer. Derfor, hvis du ønsker at ændre noget eller tilføje en ny funktion, er det muligt, at hele systemet kan gå i stykker.
Selvom den er forældet, eksisterer den indimellem stadig. Ja, vi er opmærksomme på dit nuværende udtryk.
Den konceptuelle opdeling af kodebasen i to forskellige komponenter - frontend (klient-side) og backend (server-side) - blev uundgåelig, da nye teknologier blev udviklet og softwareprodukter blev mere komplicerede.
Den mest populære betjeningsmetode er nu adskillelsen af bekymringer mellem det præsentationslag, som en slutbruger interagerer med, og alt, hvad der foregår i baggrunden.
Det har brug for to softwareingeniørteams, hvor front-end-teamet bygger de visuelle komponenter og back-end-teamet bygger webtjenesterne, forretningslogikken, dataadgang, integrationer osv.
På trods af denne adskillelse forbliver denne strategi stadig monolitisk af natur.
Den vigtigste ændring er, at vi nu har to store kodeblokke – frontend og backend – i stedet for en enorm applikation. Monolitiske arkitekturer behøver ikke at være forfærdelige; de har et par fordele, bl.a
- Enkel og hurtig udvikling til små applikationer med en enkelt kildekodebase og et meget enkelt design;
- Test og fejlretning er meget ligetil, fordi al kode er på ét sted, hvilket gør det nemmere for et team at spore en anmodnings flow og identificere fejl;
- Tidligt i udviklingen af en applikation er omkostningerne billigere, da hverken infrastrukturomkostninger eller udviklingsomkostninger afholdes, før nye funktioner tilføjes.
Ulemperne ved denne strategi afspejles i
- Begrænset implementeringsfleksibilitet – teams skal vente, hvis der kun er en håndfuld af dem, der arbejder på projektet, og ny implementering er påkrævet, hver gang du opdaterer koden;
- At adoptere nye teknologier er udfordrende, da det kræver omskrivning af en betydelig del, hvis ikke hele projektet.
- Når antallet af udviklere stiger, bliver et kodesystem tæt forbundet, kompliceret og svært at administrere og forstå.
- Organisatoriske problemer – hvert teammedlem skal bruge den samme version af biblioteker og rapportere eventuelle ændringer, hvis mange teams arbejder på et monolitisk projekt.
- Bekymringer om skalerbarhed – fordi projektets komponenter er indbyrdes forbundne, giver det vanskeligheder at skalere dem hver for sig, som resulterer i betydelig nedetid og højere udgifter.
- Projektets komplekse logik kan være vanskelig for nye teammedlemmer at forstå, især hvis de ingeniører, der oprindeligt arbejdede på det, ikke længere er ansat.
Udviklingen af mikrotjenester og deres nære slægtninge, og mikrofrontends, adresserede de primære problemer med monolitiske systemer.
Mikroservices arkitektur
Den arkitektoniske metode kendt som mikrotjenester giver mulighed for at skabe mange løst forbundne og uafhængigt deployerbare mindre komponenter eller tjenester, der udgør en applikations-backend.
Hver tjeneste har sin egen kodebase, CI/CD-pipelines, DevOps-procedurer og processer til at køre dem.
Du kan se, at det monolitiske backend-team er opdelt i separate hold ved at se på billedet ovenfor.
Hver fokuserer individuelt på et andet aspekt af applikationen (såsom produkttjenesten, søgetjenesten og betalingstjenesten).
Kommunikation mellem tjenesterne sker gennem etablerede protokoller kendt som API'er, såsom den lette REST API-protokol, der bruger synkrone anmodnings-svar-mønstre.
En anden mulighed er at bruge asynkron kommunikation ved hjælp af software som Kafka, der tilbyder publicer/abonner kommunikationsstrukturer og begivenheder.
Mikrotjenester integreres med frontend via en backend til frontend-tjenesten (BFF) eller en API-gateway gennem netværket. BFF tilbyder en tilpasset API til hver klient, hvorimod API Gateways giver et enkelt adgangspunkt til en samling af mikrotjenester.
Men selv med autonome backend-komponenter og alle de fordele, de giver, er frontenden stadig en monolit.
Derfor er det her, mikro-frontends er nyttige.
Mikro frontends arkitektur
I lighed med mikrotjenester, hvor løst forbundne komponenter administreres af flere teams, anvender mikrofrontend-arkitekturen konceptet til browseren.
Disse webapplikationsbrugergrænseflader følger denne struktur, som består af noget autonome komponenter.
Teams oprettes også på klientbehov eller use cases frem for særlig ekspertise eller teknologi.
Derfor er teams involveret i mikrotjenester og mikrofrontend-projekter.
- vertikalt skåret - da der er frontend-udviklere, dataeksperter, backend-ingeniører, QA-ingeniører osv., der også arbejder på det samme projekt, skaber de deres funktioner fra brugergrænseflade til databaser; og
- tværfunktionel – hvert teammedlem bidrager med deres ekspertise til gruppen.
Teams kan også vælge den teknologiske stak, der passer bedst til deres særlige branche.
Et team kan bruge React til at programmere sit fragment. Et andet hold opretter en ny Angular-version. Vue.js er et sådant eksempel.
Mikrofrontends bruges sammen med relaterede mikrotjenester til at løse problemer, som udviklingsteams typisk har med monolitter. Strategien giver følgende fordele.
- Teknologifrihed: Frontend-ingeniører kan vælge alternative JavaScript-rammer, runtime-miljøer og hele teknologistacks afhængigt af virksomhedens behov. Ud over den forældede arkitektur kan en ny ramme anvendes.
- En større grad af fleksibilitet er mulig, da hver mikrofrontend er selvstændig og kan udvikles, testes, implementeres og opgraderes separat. Som et resultat, hvis et team arbejder på en funktion og har skubbet en fejlrettelse, og et andet team skal tilføje sin egen funktion, behøver de ikke at vente på, at det første team fuldfører deres opgave.
- Autonome teams og systemer: Hvert produktteam, og dermed hver funktion, kan fungere med ringe afhængighed af andre, hvilket gør det muligt at fortsætte med at arbejde, selv når de nærliggende komponenter er utilgængelige.
- Flere, mindre kodebaser: Hver af mikro-frontends vil have sin egen, mere håndterbare, mindre kodebase. Færre mennesker vil fokusere på en specifik UI-komponent, forenkle kodegennemgange og forbedre den overordnede organisation.
- Enkel app-skalering: En anden fordel ved mikrofrontends er muligheden for at skalere hver funktion individuelt. I modsætning til monolitter, hvor hele programmet skal skaleres, hver gang der tilføjes en ny feature, gør det hele processen mere effektiv i forhold til både tid og penge.
Hvordan fungerer mikrofrontend?
Som vi tidligere har nævnt, er teams lodret organiseret inde i mikrofrontend-arkitekturen, hvilket betyder, at de er adskilt af domæneviden eller formål og er ansvarlige fra start til slut for et specifikt produkt.
Det kan have en eller to backend-mikrotjenester samt en lille frontend. Mere detaljeret, lad os undersøge dette visuelle elements egenskaber, interaktioner med andre UI-komponenter og inkorporering på hjemmesiden.
En mikro-frontend kan være
- en hel side (f.eks. en produktdetaljeside) eller
- sektioner af siden, som kan bruges af andre teams, såsom sidehoveder, sidefødder og søgelinjer.
Du kan opdele en stor hjemmeside i flere sidetyper og give hver type til et specifikt personale at arbejde på.
Flere komponenter forekommer dog ofte på adskillige sider, såsom sidehoveder, sidefødder, forslagsblokke osv. En forslagsblok kan for eksempel inkluderes på en hjemmeside, en produktdetaljeside eller endda betalingssiden.
I bund og grund kan hold oprette stykker, som andre hold kan bruge på deres sider.
Mikrofronterne kan dog implementeres separat som forskellige projekter i modsætning til de genanvendelige komponenter.
Alt dette lyder fantastisk, men for at skabe en samlet grænseflade skal sider og fragmenter på en eller anden måde kombineres.
Dette kræver frontend-integration, som kan opnås via en række forskellige strategier, herunder routing, sammensætning og kommunikation (se grafikken ovenfor).
Routing
Når service fra en side kontrolleret af et team er påkrævet for at få adgang til en side, der ejes af et andet team, er routing nyttig til integration på sideniveau.
Hver mikrofrontend håndteres som en enkeltsides applikation. Simple HTML-links kan bruges til at give routing.
En bruger kan tvinge browseren til at downloade målmarkeringen fra en server og erstatte den nuværende side med den nye ved at klikke på hyperlinks.
App-skallen er det absolutte minimum af HTML, CSS og JavaScript, der driver en brugergrænseflade. Selvom de indholdsdata, der anmodes om fra serveren, stadig venter, modtager brugeren en statisk vist side med det samme. Den centrale app-skal fungerer som en overordnet applikation til de enkeltsidede apps, der er oprettet af de forskellige teams.
Uanset biblioteket eller rammeværket, der bruges, muliggør meta-frameworks fusion af forskellige sider til en enkelt.
Sammensætning
Komposition er processen med at arrangere brikkerne, så de passer til de passende rum på en side. I de fleste tilfælde henter det team, der implementerer siden, ikke indholdet af fragmentet med det samme.
I stedet placerer den en pladsholder eller markør, hvor fragmentet skal være i markeringen.
Ved hjælp af en anden komponeringsproces udføres den endelige samling. Sammensætningen kan opdeles i to grundlæggende kategorier: klient-side og server-side.
Sammensætning på klientsiden: Webbrowseren bruges til at oprette og redigere HTML-markering. Hver mikrofrontend har mulighed for at ændre og vise dens markering separat fra resten af siden.
Web Components, for eksempel, giver dig mulighed for at udføre denne type konstruktion.
Planen er at omdanne hvert fragment til en webkomponent, der selvstændigt kan installeres som en a.js-fil, hvorefter apps kan indlæse og gengive dem i de områder, der er udpeget til dem i temalayoutet.
Webkomponenter er afhængige af HTML og DOM API, som andre frontend-frameworks kan bruge, samt en standardmetode til at sende og modtage data via rekvisitter og begivenheder.
Server-side sammensætning: Med dette design kombineres UI-delene på serveren, hvilket resulterer i, at en fuldstændig dannet side sendes til klientsiden, hvilket fremskynder indlæsningen.
Monteringen udføres ofte af en separat service, der sidder mellem webbrowseren og webserverne. CDN er en forekomst af tjenesten (netværk til levering af indhold).
Du kan vælge en eller en kombination af de to, afhængigt af dine behov.
Mikro frontend kommunikationsmønstre
Mikro-frontend-arkitekturen fungerer bedst, når der er lidt eller ingen interaktion mellem de forskellige komponenter. Mikrofrontends har lejlighedsvis brug for at tale med hinanden og dele information. Her er et par potentielle mønstre, der kan føre til det.
- Webarbejdere: En onlinemedarbejder er en mekanisme, der gør det muligt for webindhold at køre JavaScript i baggrunden, uafhængigt af andre scripts og uden at påvirke sidens hastighed. En unik worker API vil blive leveret til hver mikroapp. Denne fordel er, at tidskrævende arbejde kan udføres i en anden tråd, hvilket gør det muligt for UI-tråden at fortsætte uden at blive bremset eller stoppet.
- Hændelsesudsender: I dette tilfælde kommunikerer mange komponenter med hinanden ved at lytte efter og reagere på eventuelle tilstandsændringer i de komponenter, som de er abonneret på. Andre mikro-frontends, der har abonneret på den specifikke begivenhed, reagerer, når en mikro-frontend udløser denne begivenhed. En hændelsesudsender, der er blevet indført i hver mikro-frontend, gør dette muligt.
- Tilbagekald og rekvisitter: I dette afsnit definerer du en overordnet komponent og underordnede komponenter. Kommunikationen er organiseret i en trælignende struktur. Overordnede komponenter bruger rekvisitter til at formidle dataene som funktioner ned i komponenttræet til de underordnede komponenter. Til gengæld kan barnet effektivt advare forælderen, når der sker noget i deres tilstand ved at reagere på tilbagekald. React anvender denne tilstand.
Fordele ved Micro frontend
Udvikling i hurtigt autonome teams
Et uafhængigt team kan oprette hver del af en webapp eller et websted, når de bruger en mikrofrontend-metode.
Hvert team er fuldstændig autonomt, hvilket betyder, at det er ansvarligt for hele komponentudviklingscyklussen, fra idé til udgivelse og efterproduktion.
Derudover indebærer det, at forskellige teams kan samarbejde problemfrit, mens de samtidig arbejder på det samme projekt.
Derfor er frigivelsescyklusser væsentligt hurtigere, end de ville være med front-end monolitter.
Mindre kodebaser af individuelle mikrofrontends fører til renere kode
Monolitiske frontends har store, uhåndterlige kodebaser, der bliver mere og mere kaotiske og udfordrende at administrere over tid.
Mikrofrontends løser dette problem. Hver mikrofrontends kildekode er mere overskuelig, da den er mindre, enklere og mere kompakt.
Den samlede webløsning nyder godt af renere kode som konsekvens.
Forbedret app-stabilitet på grund af en løs kobling
En webløsning kan sjældent nogensinde opdeles i helt selvstændige stykker. Derfor taler mikro-frontends til hinanden.
Hver forbindelse mellem komponenterne er dog væsentlig på trods af den løse forbindelse.
Fejlen af en komponent har ringe eller ingen effekt på driften af alle de andre komponenter, hvilket giver den forbedrede stabilitet af en webløsning.
Test af individuelle funktioner er gjort enklere
Denne fordel er resultatet af egenskaberne ved mikrofrontends. Baseret på dette arkitektoniske design er en webløsnings klientside modulopbygget, og hvert modul er autonomt.
Som et resultat er det lettere for et team at evaluere en lille del af brugergrænsefladen i sig selv end at teste en massiv monolit.
Reduceret bundtstørrelse fører til hurtigere sideindlæsning
En af de primære årsager til forsinkede indlæsningstider i funktionsrige monolitiske websystemer er størrelsen af en JavaScript-pakke. På den anden side gør en mikrofrontend-tilgang det nemmere at reducere sideindlæsningstiden.
En browser behøver ikke at downloade unødvendig kode gentagne gange, da en webside består af flere små bundter. Som følge heraf øges sidens ydeevne og indlæsningstider.
Teknologisk uafhængighed
Multiple front-end rammer kan bruges af udviklere til at skabe en enkelt online løsning med en mikro-frontend-arkitektur.
Da hver komponent er autonom, kan den konstrueres ved hjælp af den teknologi, der passer bedst til holdets opgaver.
Programmører bør naturligvis være forsigtige, når de vælger rammer til det softwareprojekt, de er ansvarlige for, og konsultationer med andre teams tilrådes stadig kraftigt.
Der er dog ingen chance for, at du bliver tvunget til at bruge en ældre ramme i hele appens levetid.
Ulemper ved Micro Frontend
Kompleks webløsningstest i sin helhed
Det er nemt at teste en webløsnings forskellige moduler, når den bruger en mikro-frontend-arkitektur. Det adskiller sig dog fra at evaluere en webapplikation som helhed.
Kontroller, at alle dele fungerer efter hensigten, før du fortsætter. Dette kan være svært, da mikrofrontends fungerer uafhængigt og har separate leveringsprocesser.
Dyre startinvesteringer
Mikrofrontend-udvikling kræver typisk betydelige økonomiske udgifter. Det er dyrt at samle og holde op med mange front-end teams.
Derudover har du brug for ledelsespersonale til at organisere jobbet, sørge for at alt er koordineret og garantere fremragende teamkommunikation.
Kompleksiteten af udvikling og implementering
Udviklings- og implementeringsprocedurerne kan blive mere komplicerede som følge af et mikro-frontend-design.
En løsning kan for eksempel være rodet med for mange komponenter af uafhængige udviklingsteams, der arbejder på det samme projekt, hvilket kan forårsage problemer i implementeringsfasen.
Den rigtige samling af alle modulerne og deres smidige integration i det overordnede skema er heller ikke altid enkel; dette arbejde kræver typisk en grundig forståelse af alle afhængigheder.
Problemer med at bevare sammenhæng i brugeroplevelsen
At opretholde en ensartet brugergrænseflade er udfordrende, når teams arbejder separat på flere dele af softwaren.
Webløsningen bør deles af alle projektets udviklere. Ellers kan der være mange modsætninger undervejs.
Konklusion
Micro frontends, et moderne arkitektonisk design, kan i høj grad forbedre ydeevnen af store mikroservice-baserede webudviklingsprojekter.
Det gør det muligt for programmører at opdele den komplette løsning i diskrete dele, der kan skabes af flere selvstændige teams. Adskillige fordele følger af dette, herunder hurtigere funktionsudrulning, lettere test af individuelle moduler og mere problemfri opgraderinger.
Men der er også nogle vanskeligheder med mikro-frontends.
En applikations omfattende test kan for eksempel være udfordrende.
Fordi der er behov for et stort team af ingeniører og administratorer, er mikrofrontend-projekter desuden meget dyre.
Inden du træffer en beslutning, skal du derfor tage højde for alle komponenter i din business case.
Vladimír Čamaj
På en eller anden måde forstod jeg ikke, på hvilket princip kommunikationen mellem individuelle komponenter på frontend fungerer. Jeg forstår ikke, hvordan man vil forbinde komponenter, der er skabt i forskellige rammer. Der står intet om det i artiklen. Systemet af begivenheder og lyttere ligner helvede på jorden for mig. Hvordan skal vi forestille os det?