Indholdsfortegnelse[Skjule][At vise]
- Så hvad er et modulforbund?
- Hvorfor modulforbund?
- Modul federation kernekomponenter
Modul Federation kernefunktioner+-
- Fremragende web ydeevne
- Effektiv udvikling
- Evnen til selvhelbredelse og redundans
- Effektiv håndtering af fælles afhængigheder
- I stedet for at skulle geninstallere forbrugere, skal du implementere uafhængig kode.
- Når du kører, importer kode fra andre builds.
- Forbedret udvikleroplevelse, samtidig med at klientoplevelsen bevares
- Mikro-frontends fungerer på en monolitisk måde.
- Konklusion
Konceptet med mikrofrontends anvender mikrotjenester til frontendudvikling.
Ideen er at dele applikationen eller webstedet op i mindre, uafhængigt udviklede stykker, som derefter forbindes under kørsel, i modsætning til at skabe dem som en enkelt sammenhængende monolit.
Metoden giver dig mulighed for at oprette andre komponenter i applikationen ved hjælp af andre teknologier og med uafhængige teams.
Ideen er at reducere vedligeholdelsesudgifterne i forbindelse med en typisk monolit ved at segmentere udviklingen på denne måde.
Ved at give dem mulighed for at koncentrere sig om et bestemt område af en applikation som et sammenhængende team, gør det også nye former for samarbejde mellem backend- og frontend-udviklere mulige.
For eksempel kan du have et team, der er eneansvarlig for søgekapaciteten eller et andet aspekt af et nøgleprodukt, der er afgørende for en virksomhed.
Takket være modulføderationen har du nok funktionalitet til at håndtere den arbejdsgang, som mikro frontend tilgangsmandater.
Dette indlæg vil tage et dybt kig på arkitekturen af modulføderationen, såvel som dens hovedfunktioner og applikationsmønstre.
Så hvad er en modulforbund?
Javascripts modulføderationsdesign gør brug af genbrugte dele i mange applikationer.
Det er ret grundlæggende jargon, men jeg har simpelthen fået det til at virke på den måde, at det virker luftigt.
Da vi alle er bekendt med at dele komponenter inden for en React-applikation, opnår Module Federation effektivt det samme mål i praksis, med den undtagelse, at det dynamisk eksponerer applikationsmoduler til forbrug af andre applikationer.
Module Federation søger at overvinde problemet med moduldeling i et distribueret system ved at levere disse nøgleelementer som makro eller mikro efter ønske.
Dette opnås ved at få dem fjernet fra dine apps og build-workflowet.
Hvorfor modulforbund?
Her er nogle faktorer, som modulføderation nemt kan håndtere:
- Eksterne og DLL'er (Dynamic Link Libraries) var alt, hvad vi lejlighedsvis havde til at dele funktionalitet mellem apps. Alt dette gjorde deling af skaleringskode ekstremt udfordrende.
- NPM er træg.
- Når to separate programmer deler afgørende kode, skal de være dynamiske og fleksible.
For at selvstændige apps skal være helt i deres eget lager, installeres separat og fungere som deres egen uafhængige SPA, blev Module Federation oprettet.
Modul federation kernekomponenter
Før du dykker dybere, er det vigtigt kort at diskutere et par nye koncepter, som modulføderation bringer.
- Vært: Når en side indlæses, kaldes den opbygning eller modul, der oprindeligt blev initialiseret, en vært. En udbyder kan opfattes som en vært.
- Fjernbetjening: En fjernbetjening er en anden konstruktion, der bruger en del af værten. De kaldes også kunder.
- Bi-direktionel vært: en Webpack-build, der både fungerer som en fjernbetjening, som andre værter bruger, og en vært, der bruger fjernbetjeninger.
- Leverandørføderation: muliggør deklarativt delt runtime-deling af npm-modulafhængigheder for en vært eller fjernbetjening, uanset den placering, hvorfra de indlæses. Et af de største præstationsproblemer med mikrofrontends er løst på denne måde.
Mønstre for fødereret applikation
Evergreen Design System
En af de mest grundlæggende former for fødererede applikationer er en "evergreen remote", som er en delt fjernbetjening som et "Design System" eller "Component library", der distribueres uafhængigt og opdateres for alle brugere.
Uden at hvert app-team behøver at bruge tid på revisioner, kan dette være nyttigt til at sikre, at alle onlinesider overholder den seneste virksomhedsidentitet.
For at designe og indføre de begrænsninger og procedurer, der er nødvendige for at garantere sikre, løbende opdateringer, kan dette være et nyttigt sted for virksomheder at starte, når de overvejer en fødereret applikationsarkitektur.
Følgende er nogle anvendelsestilfælde, hvor uafhængigt implementerede delte fjernbetjeninger kan være en passende pasform:
- Design systemer
- Applikationsskaller
- Komponentbiblioteker
- Forbrugere
- Delte værktøjssæt
- Alternative distributionsmodeller for widgets, der bruges af interne eller eksterne
Multi-SPA-moduldeling
Genbrug allerede eksporterede funktioner, såsom komponenter, i forskellige enkeltsides apps. Fordelene omfatter:
- Forbrugerne modtager automatiske opdateringer
- Domæneekspertise forbliver på det team, der har ansvaret for det.
- Strømliner implementeringsproceduren, fordi separate moduludgivelser ikke er nødvendige.
Shell drevet forbund
Den shell-drevne føderation inkluderer:
- Når du opretter en ny produktversion, venter produktteamet ikke på, at Checkout-teamet fuldfører deres job.
- Når du skifter fjernbetjening, er der ingen genindlæsning af sider.
- Når det er nødvendigt, tilbyder Shell langsom fjernindlæsning og (topniveau) routing.
- Routing på tværs af fjernbetjeninger er muliggjort via leverandørforbund, som muliggør genbrug af ofte brugte npm-pakker.
- Shell tilbyder rammerne og andre almindelige afhængigheder, der genbruges af de dovne indlæste fjernbetjeninger.
Multi-shell forbund
Svarende til den shell-drevne føderation beskrevet ovenfor, men brugte forskellige skaller.
Det indeholder:
- en række skaller
- Hvid-mærkning
- Ikke alle fjernbetjeninger kræves af Shell B eller har uafhængige implementeringer.
Modul Federation kernefunktioner
Fremragende web ydeevne
Problemet med den normale NPM-modulsammensætning er, at når antallet af pårørende stiger, vokser applikationens størrelse generelt.
For at undgå at indlæse bundter, når din applikation indlæses, og kun indlæse dem, når det er nødvendigt, tilbyder Module Federation dig muligheden for dovent at indlæse bundter.
Dette forhindrer behovet for at downloade moduler, før de faktisk er nødvendige, hvilket forbedrer webstedets hastighed.
Effektiv udvikling
Hvert projekt kan produceres og leveres isoleret og kan udføres af forskellige teams, fordi Module Federation opfordrer dig til at organisere din ansøgning i diskrete projekter, så du kan bygge og implementere dem separat (og dermed parallelt).
Evnen til selvhelbredelse og redundans
Delte afhængigheder giver Modul Federation mulighed for at holde styr på alle dit programs afhængigheder på ét sted.
På denne måde, selv når en applikation ikke erklærer en afhængighed, eller når der er netværksproblemer, ved den stadig, hvad den har brug for og kan håndtere at downloade den efter behov.
Effektiv håndtering af fælles afhængigheder
Derudover tilbyder Module Federation overlegen afhængighedsstyring, der effektivt løser leverandør- og tredjepartskrav, så din applikation aldrig vil indlæse mere end én version af et bibliotek.
I stedet for at skulle geninstallere forbrugere, skal du implementere uafhængig kode.
Udvikleren er meget interesseret i at have evergreen funktionalitet. Når først synlig afhængig funktionalitet har ændret sig, vil det ikke være nødvendigt at geninstallere forbrugerne længere.
Jeg må indrømme, at dette er en meget potent funktion i sig selv, en som vil kræve omhyggelig undersøgelse for at forhindre uventede resultater.
Når du kører, importer kode fra andre builds.
Når vi anvender NPM-pakkemodellen, kan vi overveje apps, der bruger Module Federation beslægtet med API'er i stedet for at dele kode og tænke på "bibliotek".
På samme måde som de også kan modtage funktionalitet fra andre apps, kan webapplikationer nu levere funktionaliteten til andre applikationer.
Forbedret udvikleroplevelse, samtidig med at klientoplevelsen bevares
Enhver JavaScript-udvikler vil være ganske komfortabel med Module Federation, fordi det er et Webpack-plugin, der er tilgængeligt fra Webpack version 5.
Dette er faktisk ret stærkt og spændende, hvis vi tænker lidt over det.
Ved at bruge tredjeparts Webpack-indlæsere skal du overveje alle de komponenter, der webpack bundter, herunder scripts, aktiver, typografier, billeder, markdowns og mere.
Ved at bruge Modul Federation kan alle disse deles og sammenføjes.
Mikro-frontends fungerer på en monolitisk måde.
Det er ret nemt at tilføje delt funktionalitet til din applikation; bare importer bundtet som normalt eller brug synkron indlæsning.
Alternativt kan asynkron belastning bruges til kun at indlæse afhængigheder, når det er nødvendigt ved at bruge doven belastning.
Konklusion
I dette indlæg har vi diskuteret Module Federation som et fantastisk valg til at udvikle din mikro-frontend-applikation.
At lade apps udveksle og forbruge funktionalitet under kørsel fremmer skalerbarhed ved at gøre det muligt for forskellige teams at arbejde på uafhængige applikationer.
Når den fælles funktionalitet ændres, behøver du ikke designe og implementere dine forbrugere, da den understøtter evergreen-funktionalitet.
Dit program vil fungere som en monolit, når det er blevet sat op, hvilket er fantastisk.
Delbare afhængigheder bruges til at reducere størrelsen af apps. Da mange udviklere allerede er fortrolige med Webpack-miljøet, er udvikleroplevelsen fremragende.
Giv en kommentar