Innholdsfortegnelse[Gjemme seg][Forestilling]
Ideen om mikrotjenester har fått mye oppmerksomhet den siste tiden, og mange firmaer bruker den for å gjøre unna store, monolittiske backends.
Å gå den samme veien med frontend er fortsatt en utfordring for mange virksomheter, selv om denne distribuerte måten å konstruere serversiden på nettapper på er mer eller mindre pålitelig når det gjelder forskning og utførelse.
På grunn av sin nære avhengighet, gjør monolitten på klientsiden det vanligvis vanskelig å integrere nye funksjoner, ta i bruk nye teknologier og skalere individuelle komponenter.
Disse og andre utfordringer har fått frontend-utviklere til å undersøke bruken av mikrotjenester.
Som et resultat ble det utviklet en helt ny arkitektonisk strategi kjent som mikrofrontend for å lage front-end-laget av nettsteder og nettbaserte applikasjoner.
Begrepet ble først brukt i 2016, og siden den gang har det fått mye oppmerksomhet for en god sak.
Denne artikkelen vil gi en generell forståelse av hva mikrogrensesnitt er og problemene de tar opp. det fungerer, samt fordeler og ulemper.
Introduksjon til mikrofront-end-arkitektur
En moderne metode for frontend-utvikling kalt mikro-frontend-arkitektur deler en webapplikasjon i små, uavhengige deler.
For sluttbrukeren ser disse delene ut til å være én enhet selv om de ble konstruert uavhengig og deretter satt sammen.
Med den forskjellen at mikrofrontends gjelder klientsiden, ikke serversiden, til nettløsninger, er begrunnelsen for dem identisk med mikrotjenester.
Å lage sofistikerte nettbaserte produkter er mest fornuftig når du bruker en mikrofrontend-tilnærming.
Mikrofrontends, i motsetning til en mer konvensjonell frontend-monolit, gjør det mulig for mange team å samarbeide separat om ulike programvareprosjekter.
Programmerere kan lage nettapper raskere og med større skalerbarhet og vedlikeholdsmuligheter ved å bruke dette arkitektoniske designet.
For å si det enkelt, er hver mikrofrontend bare et stykke kode for en distinkt komponent av nettsiden.
Disse funksjonene styres av separate team, som hver spesialiserer seg på en bestemt bransje eller mål.
Monolithic vs Microservices vs Micro frontend-arkitektur
Tenk å flytte. Vil det være enklere for deg å organisere alt i et antall små, ekspertmerkede bokser og flytte hver enkelt individuelt eller pakke hele personalet i en enorm boks og transportere det til et nytt sted?
Den åpenbare løsningen er der.
Denne analogien sammenligner de to distinkte nettapp-arkitekturene, monolittene og mikrotjenester (også kjent som mikrofrontends).
Monolitisk arkitektur
Du kan kanskje huske de "gode gamle dagene" da en komplett applikasjon ble opprettet som en enkelt, sammenhengende enhet. En slik metode kalles en monolitt, som er en gammel betegnelse på en stor steinblokk.
Dette gir mening.
Monolittiske systemer har gjensidig avhengige elementer. Derfor, hvis du ønsker å endre noe eller legge til en ny funksjon, er det mulig at hele systemet kan gå i stykker.
Selv om den er foreldet, eksisterer den av og til fortsatt. Ja, vi er klar over ditt nåværende uttrykk.
Den konseptuelle inndelingen av kodebasen i to forskjellige komponenter - frontend (klient-side) og backend (server-side) - ble uunngåelig etter hvert som nye teknologier ble utviklet og programvareprodukter ble mer kompliserte.
Den mest populære operasjonsmetoden er nå separasjonen av bekymringer mellom presentasjonslaget som en sluttbruker samhandler med og alt som foregår i bakgrunnen.
Den trenger to programvareingeniørteam, med front-end-teamet som bygger de visuelle komponentene og back-end-teamet som bygger webtjenester, forretningslogikk, datatilgang, integrasjoner, etc.
Til tross for denne separasjonen forblir denne strategien fortsatt monolitisk av natur.
Hovedendringen er at vi nå har to store blokker med kode – frontend og backend – i stedet for en enorm applikasjon. Monolittiske arkitekturer trenger ikke å være forferdelige; de har noen fordeler, inkludert
- Enkel og rask utvikling for bittesmå applikasjoner med en enkelt kildekodebase og et veldig enkelt design;
- Testing og feilsøking er veldig enkelt fordi all kode er på ett sted, noe som gjør det lettere for et team å spore en forespørsels flyt og identifisere feil;
- Tidlig i utviklingen av en applikasjon er utgiftene billigere siden verken infrastrukturkostnader eller utviklingskostnader påløper før nye funksjoner legges til.
Ulempene med denne strategien gjenspeiles i
- Begrenset distribusjonsfleksibilitet – team må vente hvis det bare er en håndfull av dem som jobber med prosjektet og ny distribusjon er nødvendig hver gang du oppdaterer koden;
- Å ta i bruk nye teknologier er utfordrende siden dette krever omskrivning av en betydelig del, om ikke hele prosjektet.
- Når antallet utviklere øker, blir et kodesystem tett forbundet, komplisert og vanskelig å administrere og forstå.
- Organisatoriske problemer – hvert teammedlem må bruke samme versjon av biblioteker og rapportere eventuelle endringer hvis mange team jobber med et monolitisk prosjekt.
- Bekymringer med skalerbarhet – fordi prosjektets komponenter er sammenkoblet, gir det å skalere dem separat vanskeligheter som resulterer i betydelig nedetid og høyere utgifter.
- Prosjektets komplekse logikk kan være vanskelig for nye teammedlemmer å forstå, spesielt hvis ingeniørene som opprinnelig jobbet med det ikke lenger er ansatt.
Utviklingen av mikrotjenester og deres nære slektninger, og mikrofrontends, adresserte de primære problemene med monolitiske systemer.
Mikrotjenester arkitektur
Den arkitektoniske metoden kjent som mikrotjenester gjør det mulig å lage mange løst koblede og uavhengig distribuerbare mindre komponenter, eller tjenester, som utgjør en applikasjonsbackend.
Hver tjeneste har sin egen kodebase, CI/CD-pipelines, DevOps-prosedyrer og prosesser for å kjøre dem.
Du kan se at det monolittiske backend-teamet er delt inn i separate team ved å se på bildet ovenfor.
Hver fokuserer individuelt på et annet aspekt av applikasjonen (som produkttjenesten, søketjenesten og betalingstjenesten).
Kommunikasjon mellom tjenestene skjer gjennom etablerte protokoller kjent som APIer, for eksempel den lette REST API-protokollen som bruker synkrone forespørsel-svar-mønstre.
Et annet alternativ er å bruke asynkron kommunikasjon ved å bruke programvare som Kafka, som tilbyr publiserings-/abonnerkommunikasjonsstrukturer og -hendelser.
Mikrotjenester integreres med frontend via en backend for frontend-tjenesten (BFF) eller en API-gateway gjennom nettverket. BFF tilbyr et tilpasset API for hver klient, mens API Gateways gir ett enkelt tilgangspunkt for en samling mikrotjenester.
Men selv med autonome backend-komponenter og alle fordelene de gir, er frontend fortsatt en monolitt.
Derfor er det her mikrofrontends er nyttige.
Mikrofrontend-arkitektur
I likhet med mikrotjenester, hvor løst koblede komponenter administreres av flere team, bruker mikrofrontend-arkitekturen konseptet til nettleseren.
Disse webapplikasjonsbrukergrensesnittene følger denne strukturen, som består av noe autonome komponenter.
Team opprettes også på klientbehov eller brukssaker i stedet for spesiell ekspertise eller teknologi.
Følgelig er team involvert i mikrotjenester og mikrofrontend-prosjekter.
- vertikalt oppskåret — siden det er frontend-utviklere, dataeksperter, backend-ingeniører, QA-ingeniører osv. som også jobber med det samme prosjektet, lager de funksjonene sine fra brukergrensesnitt til databaser; og
- tverrfunksjonell – hvert teammedlem bidrar med sin ekspertise til gruppen.
Lag kan også velge den teknologistabelen som passer best for deres spesielle bransje.
Ett team kan bruke React til å programmere fragmentet sitt. Et annet team lager en ny Angular-versjon. Vue.js er et slikt eksempel.
Mikrogrensesnitt brukes i forbindelse med relaterte mikrotjenester for å løse problemer som utviklingsteam vanligvis har med monolitter. Strategien gir følgende fordeler.
- Teknologifrihet: Frontend-ingeniører kan velge alternative JavaScript-rammeverk, kjøretidsmiljøer og hele teknologistabler avhengig av bedriftens behov. På toppen av den utdaterte arkitekturen kan et nytt rammeverk bli brukt.
- En større grad av fleksibilitet er mulig siden hver mikrofrontend er selvstendig og kan utvikles, testes, distribueres og oppgraderes separat. Som et resultat, hvis ett team jobber med en funksjon og har presset en feilretting, og et annet team må legge til sin egen funksjon, trenger de ikke å vente på at det første teamet skal fullføre oppgaven.
- Autonome team og systemer: Hvert produktteam, og følgelig hver funksjon, kan fungere med liten avhengighet av andre, noe som gjør at det kan fortsette å fungere selv når de nærliggende komponentene er utilgjengelige.
- Flere, mindre kodebaser: Hver av mikrogrensesnittene vil ha sin egen, mer håndterbare, mindre kodebase. Færre mennesker vil fokusere på en spesifikk UI-komponent, forenkle kodegjennomganger og forbedre den generelle organisasjonen.
- Enkel appskalering: En annen fordel med mikrofrontends er muligheten til å skalere hver funksjon individuelt. I motsetning til monolitter, hvor hele programmet må skaleres hver gang en ny funksjon legges til, gjør dette hele prosessen mer effektiv både med tanke på tid og penger.
Hvordan fungerer mikrofrontend?
Som vi tidligere har sagt, er team vertikalt organisert inne i mikrofrontend-arkitekturen, noe som betyr at de er atskilt av domenekunnskap eller formål og er ansvarlige fra begynnelse til slutt for et spesifikt produkt.
Den kan ha en eller to backend-mikrotjenester samt en liten frontend. Mer detaljert, la oss undersøke dette visuelle elementets egenskaper, interaksjoner med andre brukergrensesnittkomponenter og inkorporering på hjemmesiden.
En mikro-frontend kan være
- en hel side (f.eks. en produktdetaljside) eller
- deler av siden som kan brukes av andre team, for eksempel topptekster, bunntekster og søkefelt.
Du kan dele opp et stort nettsted i flere sidetyper og gi hver type til et spesifikt personale å jobbe med.
Imidlertid forekommer flere komponenter ofte på en rekke sider, som topptekster, bunntekster, forslagsblokker osv. En forslagsblokk kan for eksempel inkluderes på en hjemmeside, en produktdetaljside eller til og med betalingssiden.
I hovedsak kan lag lage deler som andre lag kan bruke på sidene sine.
Mikrofrontene kan imidlertid distribueres separat som forskjellige prosjekter i motsetning til de gjenbrukbare komponentene.
Alt dette høres fantastisk ut, men for å skape et enhetlig grensesnitt må sider og fragmenter på en eller annen måte kombineres.
Dette krever frontend-integrasjon, som kan oppnås via en rekke strategier, inkludert ruting, komposisjon og kommunikasjon (se grafikken over).
Routing
Når tjeneste fra en side kontrollert av ett team kreves for å få tilgang til en side som eies av et annet team, er ruting nyttig for integrasjon på sidenivå.
Hver mikrofrontend håndteres som en enkeltsides applikasjon. Enkle HTML-lenker kan brukes for å gi ruting.
En bruker kan tvinge nettleseren til å laste ned målmarkeringen fra en server og erstatte gjeldende side med den nye ved å klikke på hyperkoblinger.
App-skallet er et minimum av HTML, CSS og JavaScript som driver et brukergrensesnitt. Selv om innholdsdataene som er forespurt fra serveren fortsatt venter, mottar brukeren en statisk vist side med en gang. Det sentrale app-skallet fungerer som en overordnet applikasjon for enkeltside-appene som er laget av de ulike teamene.
Uansett bibliotek eller rammeverk som brukes, muliggjør meta-rammeverk sammenslåing av ulike sider til én enkelt.
sammensetning
Komposisjon er prosessen med å arrangere brikkene for å passe dem inn i de riktige stedene på en side. I de fleste tilfeller henter ikke teamet som distribuerer siden innholdet i fragmentet umiddelbart.
I stedet plasserer den en plassholder eller markør der fragmentet skal være i markeringen.
Ved å bruke en annen komponeringsprosess, er den endelige monteringen fullført. Sammensetningen kan deles inn i to grunnleggende kategorier: klientside og serverside.
Komposisjon på klientsiden: Nettleseren brukes til å lage og redigere HTML-oppmerking. Hver mikrofrontend har muligheten til å endre og vise markeringen sin separat fra resten av siden.
Web Components, for eksempel, lar deg utføre denne typen konstruksjon.
Planen er å gjøre hvert fragment om til en nettkomponent som kan installeres uavhengig som en a.js-fil, hvoretter appene kan lastes inn og gjengi dem på plassene som er utpekt for dem i temaoppsettet.
Webkomponenter er avhengig av HTML og DOM API, som andre frontend-rammeverk kan bruke, samt en standard metode for å sende og motta data via rekvisitter og hendelser.
Komposisjon på serversiden: Med denne utformingen blir UI-delene kombinert på serveren, noe som resulterer i at en fullstendig dannet side sendes til klientsiden, noe som øker belastningen.
Monteringen utføres ofte av en egen tjeneste som sitter mellom nettleseren og nettserverne. CDN er en forekomst av tjenesten (nettverk for innholdslevering).
Du kan velge en eller en kombinasjon av de to, avhengig av dine behov.
Mikro frontend kommunikasjonsmønstre
Mikro-frontend-arkitekturen fungerer best når det er liten eller ingen interaksjon mellom de ulike komponentene. Mikrogrensesnitt trenger noen ganger å snakke med hverandre og dele informasjon. Her er noen potensielle mønstre som kan føre til det.
- Nettarbeidere: En nettbasert arbeider er en mekanisme som gjør at nettinnhold kan kjøre JavaScript i bakgrunnen, uavhengig av andre skript, og uten å påvirke hastigheten på siden. En unik arbeider-API vil bli gitt for hver mikroapp. Denne fordelen er at tidkrevende arbeid kan gjøres i en annen tråd, slik at UI-tråden kan fortsette uten å bli bremset eller stoppet.
- Hendelsesmitter: I dette tilfellet kommuniserer mange komponenter med hverandre ved å lytte etter og reagere på eventuelle tilstandsendringer i komponentene de abonnerer på. Andre mikrogrensesnitt som har abonnert på den spesifikke hendelsen, reagerer når en mikrogrensesnitt utløser den hendelsen. En hendelsessender som er introdusert i hver mikrofrontend gjør dette mulig.
- Tilbakeringinger og rekvisitter: I denne delen definerer du en overordnet komponent og underordnede komponenter. Kommunikasjonen er organisert i en trelignende struktur. Overordnede komponenter bruker rekvisitter for å formidle dataene som funksjoner nedover komponenttreet til de underordnede komponentene. På sin side kan barnet effektivt varsle forelderen når noe skjer i deres tilstand ved å svare på tilbakeringinger. React bruker denne modusen.
Fordeler med Micro-frontend
Utvikling i raskt autonome team
Et uavhengig team kan lage hver del av en nettapp eller et nettsted når de bruker en mikrofrontend-metode.
Hvert team er helt autonomt, noe som betyr at det er ansvarlig for hele komponentutviklingssyklusen, fra unnfangelse til utgivelse og etterproduksjon.
I tillegg innebærer det at ulike team kan samarbeide sømløst mens de samtidig jobber med det samme prosjektet.
Derfor er utgivelsessyklusene betydelig raskere enn de ville vært med frontend-monolitter.
Mindre kodebaser av individuelle mikrogrensesnitt fører til renere kode
Monolittiske grensesnitt har store, uhåndterlige kodebaser som blir stadig mer kaotiske og utfordrende å administrere over tid.
Mikrogrensesnitt løser dette problemet. Kildekoden til hver mikrofrontend er mer håndterlig siden den er mindre, enklere og mer kompakt.
Den samlede nettløsningen drar nytte av renere kode som en konsekvens.
Forbedret app-stabilitet på grunn av en løs kobling
En webløsning kan sjelden deles opp i helt uavhengige deler. Følgelig snakker mikrogrensesnitt med hverandre.
Imidlertid er hver kobling mellom komponentene betydelig til tross for den løse tilkoblingen.
Svikt i en komponent har liten eller ingen effekt på driften av alle de andre komponentene, noe som gir den forbedrede stabiliteten til en webløsning.
Testing av individuelle funksjoner er gjort enklere
Denne fordelen er resultatet av egenskapene til mikrofrontends. Basert på dette arkitektoniske designet er klientsiden til en nettløsning modulær og hver modul er autonom.
Som et resultat er det lettere for et team å evaluere en liten del av brukergrensesnittet alene enn å teste en massiv monolitt.
Redusert buntstørrelse fører til raskere sideinnlasting
En av hovedårsakene til forsinkede lastetider i funksjonsrike monolittiske nettsystemer er størrelsen på en JavaScript-pakke. På den andre siden gjør en mikrofrontend-tilnærming det enklere å redusere sideinnlastingstiden.
En nettleser trenger ikke å laste ned unødvendig kode gjentatte ganger siden en nettside består av flere små bunter. Som et resultat øker sideytelsen og lastetidene.
Teknologiuavhengighet
multiple front-end rammer kan brukes av utviklere til å lage en enkelt nettløsning med en mikro-frontend-arkitektur.
Siden hver komponent er autonom, kan den konstrueres med den teknologien som passer teamets oppgaver best.
Naturligvis bør programmerere være forsiktige når de velger rammeverk for programvareprosjektet de har ansvaret for, og konsultasjoner med andre team anbefales fortsatt sterkt.
Det er imidlertid null sjanse for at du blir tvunget til å bruke et eldre rammeverk i løpet av appens levetid.
Ulemper med Micro Frontend
Kompleks nettløsningstesting i sin helhet
Det er enkelt å teste en webløsnings ulike moduler når den bruker en mikro-frontend-arkitektur. Det skiller seg imidlertid fra å evaluere en nettapplikasjon som helhet.
Kontroller at alle deler fungerer som tiltenkt før du fortsetter. Dette kan være vanskelig siden mikrofrontends opererer uavhengig og har separate leveringsprosesser.
Dyre førstegangsinvesteringer
Mikrofrontend-utvikling krever vanligvis betydelige økonomiske utgifter. Det er dyrt å sette sammen og holde oppe mange front-end-team.
I tillegg trenger du lederpersonell for å organisere jobben, sørge for at alt er koordinert og garantere utmerket teamkommunikasjon.
Kompleksiteten i utvikling og distribusjon
Utviklings- og distribusjonsprosedyrene kan bli mer kompliserte som et resultat av en mikro-frontend-design.
En løsning kan være rotete med for mange komponenter av uavhengige utviklingsteam som for eksempel jobber med det samme prosjektet, noe som kan forårsake problemer på utrullingsstadiet.
Riktig montering av alle modulene og deres jevne integrering i det overordnede opplegget er heller ikke alltid enkelt; dette arbeidet krever vanligvis en grundig forståelse av alle avhengighetene.
Problemer med å opprettholde sammenheng i brukeropplevelsen
Å opprettholde et konsistent brukergrensesnitt er utfordrende når team jobber separat på flere deler av programvaren.
Nettløsningen bør deles av alle prosjektets utviklere. Ellers kan det bli mange motsetninger langs veien.
konklusjonen
Mikrofrontends, en moderne arkitektonisk design, kan i stor grad forbedre ytelsen til storskala mikrotjenestebaserte webutviklingsprosjekter.
Den gjør det mulig for programmerere å dele opp den komplette løsningen i diskrete deler som kan lages av flere autonome team. Tallrike fordeler følger av dette, inkludert raskere funksjonsutrulling, enklere testing av individuelle moduler og mer sømløse oppgraderinger.
Men det er noen problemer med mikrofrontends også.
En applikasjons omfattende testing kan for eksempel være utfordrende.
I tillegg, fordi et stort team av ingeniører og administratorer er nødvendig, er mikrofrontend-prosjekter svært kostbare.
Følgelig, før du tar en avgjørelse, må du ta hensyn til alle komponentene i forretningssaken din.
Vladimír Čamaj
På en eller annen måte forsto jeg ikke på hvilket prinsipp kommunikasjonen mellom individuelle komponenter på frontend fungerer. Jeg forstår ikke hvordan du vil koble sammen komponenter som er laget i forskjellige rammer. Det står ingenting om det i artikkelen. Systemet av hendelser og lyttere ser ut som et helvete på jord for meg. Hvordan skal vi forestille oss det?