Cum funcționează microfrontend-urile: arhitectură, modele și exemple

Acasă » Piton » Cum funcționează microfrontend-urile: arhitectură, modele și exemple

Microfrontend-urile au devenit unul dintre cele mai discutate modele de arhitectură frontend pentru echipele care au depășit monolitul clasic cu o singură pagină. Când ai zeci de dezvoltatori care lucrează cu aceeași bază de cod, ciclurile de lansare încetinesc, regresiile se strecoară peste tot, iar micile modificări ale interfeței utilizator necesită brusc o coordonare masivă. Microfrontend-urile atacă exact această problemă prin împărțirea interfeței utilizator în bucăți construite și implementate independent.

În acest ghid vom analiza ce sunt microfrontend-urile, de ce au apărut și cum se leagă de microservicii., ce idei de bază ar trebui să respectați atunci când le proiectați și cum funcționează acestea în practică cu tehnologii precum React, Angular, Next.js, componente web, Webpack Module Federation și Single-SPA. De asemenea, vom aprofunda modele arhitecturale reale, bune practici, capcane comune și exemple concrete, cum ar fi un catalog de produse și un coș de cumpărături implementate ca microfrontend-uri separate.

Ce sunt microfrontend-urile și de ce au apărut?

Termenul „micro frontend” a fost popularizat în jurul anului 2016 în ThoughtWorks Technology Radar. ca răspuns la o tendință foarte concretă: arhitecturile backend se îndreptau către microservicii, dar partea de browser a rămas un monolit mare și fragil, deținut de o singură echipă. În timp, acel SPA „fat client” devine greu de dezvoltat, chiar dacă backend-ul este împărțit frumos în servicii mici.

Un microfrontend este, în esență, ideea de microserviciu aplicată interfeței utilizator a browserului.În loc de un singur depozit frontend mare, interfața utilizator este compusă din mai multe aplicații mai mici, autonome. Fiecare dintre ele deține un domeniu de afaceri clar (de exemplu, „finalizare comandă”, „căutare produse”, „profiluri studenți”) și poate fi construită, testată și implementată în ritmul său propriu.

La fel cum microserviciile împart logica backend în unități separate implementabile, microfrontend-urile împart frontend-ul în felii verticale. care se întind de la baza de date sau API-uri, prin backend, până la interfața cu utilizatorul. O echipă interfuncțională deține acea secțiune verticală de la un capăt la altul, de la schema de date la componentele UI.

Această „organizare verticală” contrastează cu o divizare orizontală pe straturi (o echipă pentru interfață utilizator, alta pentru API-uri, alta pentru bază de date). Echipele verticale tind să livreze mai rapid, deoarece nu trebuie să coordoneze fiecare mică modificare la nivelul unei jumătăți a companiei.

Din punct de vedere al aplicației, un microfrontend este o aplicație web autonomă. care poate fi compusă într-o experiență mai amplă: poate avea propria rutare, management de stare, sistem de proiectare și conductă de implementare, atâta timp cât respectă un set de contracte cu restul sistemului (URL-uri, evenimente, API-uri, biblioteci partajate etc.).

Idei și principii de bază din spatele microfrontend-urilor

Mai multe principii recurente apar în arhitecturile microfrontend de succesNu sunt reguli stricte, dar te vor scuti de multă durere dacă le folosești ca balustrade.

Agnosticismul tehnologic este unul dintre cele mai faimoase principii: fiecare echipă ar trebui să poată alege și actualiza stiva sa tehnologică fără a se sincroniza cu toți ceilalți. Poate că un microfrontend este pe React, altul în Angular și unul vechi în Vue. Abstracțiunile native ale browserului, cum ar fi elementele personalizate (componentele web), ajută la ascunderea acestor diferențe în spatele unei API DOM standard.

Izolarea puternică între bazele de cod ale echipelor este un alt obiectiv cheieÎn mod ideal, microfrontend-urile nu partajează un runtime JavaScript sau variabile globale. Fiecare pachet este autonom, își încarcă propriile dependențe și nu se bazează pe stări ascunse față de altele. Acest lucru reduce cuplarea accidentală și face implementările independente mult mai realiste.

Pentru a evita conflictele de denumire, echipele se pun adesea de acord asupra spațiilor de nume explicite. pentru clase CSS, evenimente DOM, chei localStorage, cookie-uri sau chiar nume de etichete de elemente personalizate. De exemplu, o echipă de finalizare a comenzii ar putea prefixa lucruri cu chk- sau folosiți o etichetă precum <blue-buy>, în timp ce o echipă de recomandări folosește rec- or <green-recos>Dintr-o privire, DOM-ul vă spune cine deține fiecare piesă.

Un alt principiu este de a prefera capacitățile native ale browserului în locul API-urilor globale personalizate.În loc să inventați un sistem PubSub universal, vă puteți baza pe evenimente DOM standard, CustomEvent, API-ul istoric pentru rutare sau DOM-ul în sine ca strat de integrare. Ori de câte ori aveți nevoie de un API partajat, păstrați-l cât mai mic și stabil posibil.

În cele din urmă, reziliența ar trebui să facă parte din proiectare încă din prima zi.Fiecare microfrontend ar trebui să ofere o anumită valoare atunci când JavaScript este lent, eșuează sau este blocat. Tehnici precum randarea pe server, îmbunătățirea progresivă și ecranele schelet ajută la menținerea unei performanțe percepute ridicate chiar și în condiții de rețea precare.

Ce este o „aplicație web modernă” în acest context?

Nu orice site web are nevoie de microfrontend-uri sau de o strategie complexă de integrare în browserUn model mental bun provine din „continuumul documente-aplicații”: în stânga aveți în mare parte documente statice legate între ele; în dreapta aveți aplicații complet interactive, cum ar fi un editor foto online.

Dacă proiectul dvs. este mai apropiat de documente statice, o compoziție simplă randată pe server este adesea suficientă.Serverul colectează fragmente HTML din diferite surse, le combină și le trimite browserului. Actualizările se fac prin încărcarea completă a paginii sau prin mici injecții Ajax, iar acest lucru este perfect normal.

Când te îndrepți către experiențe mai dinamice, asemănătoare aplicațiilor—feedback instantaneu, lucru offline, actualizări optimiste ale interfeței utilizator —integrarea pură pe server nu mai este suficientă. Ai nevoie de compoziție pe partea clientului, gestionare a stării și rutare. Aici devin interesante microfrontend-urile: îți oferă o modalitate de a scala această complexitate în cadrul mai multor echipe.

Organizare verticală și felii bazate pe domeniu

O recomandare comună este alinierea microfrontend-urilor cu domeniile de business în loc de straturile tehnice.Gândiți-vă în termeni de parcursuri ale utilizatorilor: „coș de cumpărături”, „detalii produs”, „utilizatori administratori”, „programe de cursuri”, „înregistrări studenți”, „facturi” etc.

Fiecare dintre aceste domenii poate deveni propriul microfrontend cu o responsabilitate bine definită.Într-un sistem universitar, o aplicație ar putea gestiona profilurile studenților, o alta profilurile personalului, o a treia orarul cursurilor și o alta interfața cu rezultatele examenelor. Acestea au în comun o interfață de shell și poate chiar un anumit stil, dar fiecare este o aplicație independentă din perspectiva implementării.

O bună secționare ia în considerare și contextele delimitate ale microserviciilor backend.În mod ideal, microfrontend-ul pentru „facturare” comunică în principal cu microserviciile de facturare, frontend-ul pentru „catalog” comunică cu serviciile de catalog și așa mai departe. Acest lucru menține coeziunea fiecărei secțiuni verticale și reduce dependențele între echipe.

Integrare tehnică: DOM ca API și componente web

În arhitecturile microfrontend pe partea de browser, DOM-ul în sine acționează adesea ca API-ul principal de integrare.În loc să apeleze direct codul JavaScript al celorlalți, echipele expun funcționalități prin elemente HTML, atribute și evenimente.

Elementele personalizate (parte a componentelor web) sunt o primitivă puternică pentru aceastaO echipă poate construi o funcționalitate folosind orice framework dorește și apoi o poate încadra într-o etichetă personalizată, de exemplu <order-minicart></order-minicart>Contractul public al componentei respective este definit de numele etichetei sale, atribute și evenimente emise, nu de implementarea sa internă.

Compatibilitatea browserului cu Custom Elements v1 este acum solidă în toate browserele majore, ceea ce înseamnă că rareori ai nevoie de polyfill-uri. Majoritatea framework-urilor mainstream – React, Vue, Angular, Svelte, Preact – pot reda sau încorpora elemente personalizate ca și cum ar fi etichete HTML obișnuite, iar multe dintre ele pot fi, de asemenea, compilate într-un element personalizat.

Modelul de integrare arată cam așaun microfrontend pentru „pagina de produs” decide ce funcții apar pe pagină (selectori, butoane de cumpărare, mini-coș, recomandări). Injectează elemente personalizate, cum ar fi <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>Echipele care dețin acele caracteristici își înregistrează elementele la customElements.define și implementați apeluri inverse pentru ciclul de viață, cum ar fi connectedCallback or attributeChangedCallback.

Când o variantă de produs se modifică, pagina poate fie să recreeze elementul, fie să actualizeze doar atributele acestuia.Dacă componenta observă atribute relevante, se poate re-renda. Intern, componenta ar putea utiliza șiruri de șablon, React, Vue sau orice motor de randare; integratorul nu trebuie să aibă grijă.

Comunicare pe partea clientului: evenimente și relații DOM

Transmiterea atributelor funcționează bine pentru scenariile de „introducere a datelor” într-o singură direcție, dar multe interacțiuni reale necesită ca componentele să răspundă mediului lor sau fraților/surorilor. Un exemplu tipic este un buton „cumpără” care trebuie să notifice mini-căruciorul atunci când este adăugat un articol.

În loc să construiești o magistrală de evenimente globală personalizată, te poți baza pe evenimentele browseruluiExpedierea componentelor CustomEvent instanțe care apar prin arborele DOM. Un element părinte sau chiar window poate asculta acele evenimente și orchestra răspunsuri.

De exemplu, butonul de cumpărare ar putea emite un eveniment de genul blue:basket:changed cu sarcina utilă actuală a coșuluiCăruciorul mic se abonează la evenimentul respectiv pe window sau pe un element de container partajat și își reîmprospătează starea internă de fiecare dată când se declanșează.

Această abordare menține componentele independenteButonul de cumpărare nu are nicio idee cine, dacă există cineva, ascultă evenimentele sale. Își îndeplinește doar contractul. Iar mini-căruciorul depinde doar de semantica evenimentelor, nu și de detaliile de implementare ale altor fragmente.

Randare pe server și componente universale

Dacă vă interesează performanța la prima descriere, SEO sau rezistența în cazul erorilor JavaScript, randarea pe server (SSR) este esențială.Componentele web exclusiv pe partea de client apar doar după descărcarea și rularea pachetului JS, ceea ce poate însemna un ecran alb în rețelele lente.

O soluție pragmatică este combinarea elementelor personalizate cu includeri pe server (SSI/ESI)Fiecare microfrontend expune un endpoint HTTP care returnează codul HTML pentru fragmentul său, de exemplu /blue-buy?sku=t_porschePagina principală, redată de o aplicație shell sau gazdă, include substituenți precum <!--#include virtual="/blue-buy?sku=t_porsche" --> pe care serverul web (adesea nginx) o extinde înainte de a trimite răspunsul către browser.

În timpul execuției în browser, același element personalizat este hidratat sau reinițializat. odată ce pachetul său JS se încarcă. Aceasta vă oferă o componentă „universală”: se poate reda pe server pentru viteză și SEO, apoi se poate comporta ca un element personalizat complet interactiv pe client.

Un dezavantaj al SSR cu includeri este că cel mai lent fragment dictează timpul total de răspuns.Cache-ul la nivel de fragment este aproape obligatoriu. Pentru elementele scumpe și extrem de personalizate (cum ar fi recomandările), puteți sări peste randarea pe server și să le încărcați asincron pe client.

Ecranele scheletice sunt un compromis bun pentru a evita schimbările bruște de aspectUn fragment poate afișa pe server un provizoriu gri cu aproximativ aceeași dimensiune ca și conținutul final. Când datele reale ajung pe partea clientului, scheletul este schimbat fără reflow-uri majore.

Încărcarea datelor și performanța percepută

Într-o lume microfrontend trebuie să te gândești cu atenție la unde și când sunt preluate datele.Puteți prelua totul de pe server, totul de pe client sau puteți utiliza o variantă hibridă. Fiecare alegere afectează strategiile de caching, timpul de interacțiune și viteza percepută.

Server-ul include și încurajează în mod natural preluările pe server per fragmentFiecare microfrontend comunică cu serviciile sale backend, redă HTML-ul și îl returnează shell-ului. Acel HTML poate fi memorat în cache independent de alte fragmente, ceea ce ajută la scalarea părților cu trafic intens, cum ar fi autentificarea sau lista de produse.

Când încărcați date pe client, ar trebui să bugetați stări progresive: schelet inițial, actualizări rapide atunci când atributele se modifică și comportament de rezervă atunci când API-urile sunt lente. Uneori, păstrarea datelor vechi la locul lor până la sosirea datelor noi este mai puțin deranjantă vizual decât afișarea unui schelet pentru fiecare modificare minoră.

Microfrontend-uri cu React

React este o alegere foarte populară pentru implementarea microfrontend-urilor datorită ecosistemului său și optimizărilor de randare.DOM-ul virtual și diferențierea simplifică actualizarea unor părți mici ale interfeței utilizator pe baza modificărilor prop sau a stării globale și puteți grupa aplicațiile React fie ca SPA-uri independente, fie ca elemente personalizate.

Migrarea între versiunile de React tinde să fie incrementală și relativ ușoară. în comparație cu alte framework-uri, ceea ce este util atunci când multe echipe independente mențin microfrontend-uri separate. Nu este nevoie ca toate fragmentele să treacă de la o versiune majoră la alta în același timp.

Reversul medaliei este că microfrontend-urile React descentralizate pot crea o extindere a resurselor.: echipe multiple, canale multiple de CI/CD, multe pachete, multe repozitorii mici. Fără suficientă automatizare pentru compilare, furnizare și observabilitate, această suprasarcină devine greu de gestionat.

O altă problemă practică este dimensiunea pachetuluiDacă fiecare microfrontend livrează propria copie de React și biblioteci partajate, dimensiunea totală a descărcării poate crește exploziv, mai ales când sunt necesare mai multe fragmente pentru a reda o pagină. Soluții precum Module Federation (pentru partajarea dependențelor în timpul rulării) sau o stivă puternic aliniată între echipe pot atenua acest lucru.

Microfrontend-uri cu Angular

Angular se pretează bine la configurații de microfrontend mai puternice, în special atunci când utilizați monorepo-uri și instrumentele din jurul lor (cum ar fi Nx). Spațiile de lucru Angular sunt organizate în proiecte și biblioteci, ceea ce face naturală împărțirea unei soluții mari în mai multe aplicații și biblioteci partajate.

De la Angular 12 și Webpack 5, Module Federation a devenit un cetățean de primă clasă.Un proiect Angular poate fi configurat ca gazdă sau remote folosind comenzi schematice, conectând componentele necesare. webpack.config.js și logica bootstrap pentru tine.

În acest model, aplicația Angular „gazdă” acționează ca shell care orchestrează navigarea, starea partajată și partajarea dependențelor. Microfrontend-urile Angular individuale (remote) expun module Angular pe care gazda le poate încărca dinamic prin Module Federation.

Primitivele de rutare Angular obișnuite se aplică în continuareÎn cadrul unui microfrontend, utilizați RouterModule.forChild pentru definițiile rutelor copil, astfel încât gazda să fie singura care folosește forRootÎn acest fel, mai multe aplicații Angular pot coexista sub un spațiu URL unificat, fără conflicte de router.

Federația de module în practică (exemplu Angular)

Webpack Module Federation este o caracteristică Webpack 5 care permite mai multor versiuni să partajeze cod în timpul rulării.O versiune (gazda) încarcă dinamic modulele expuse de alte versiuni (remote) prin intermediul unui fișier manifest de mici dimensiuni, denumit de obicei remoteEntry.js.

În Angular poți construi asta destul de repedeDe exemplu, ați putea crea o aplicație gazdă (host-app) și apoi rulați o schemă de genul ng add @angular-architects/module-federation --project host-app --port 4200Aceasta configurează ModuleFederationPlugin, fișierele de bootare și logica de execuție.

Apoi creați două aplicații Angular la distanță: una pentru un catalog de produse și una pentru un coș de cumpărături.Fiecare aplicație primește propriul port (de exemplu, 4201 pentru products-app, 4202 pentru cart-app) și propria configurație de federare a modulelor. În webpack.config.js a fiecărei telecomenzi pe care o folosești exposes să publice un modul (de obicei modulul principal al aplicației) sub o cheie precum ./ProductsModule or ./CartModule.

Shell-ul gazdă definește apoi rute care încarcă în mod leneș acele module la distanță. de loadRemoteModule de la @angular-architects/module-federationDe exemplu, navigarea către /products declanșează un import dinamic din http://localhost:4201/remoteEntry.js și încărcături ProductsModule; /cart face același lucru și cu telecomanda căruciorului.

În microfrontend-ul catalogului este posibil să aveți un ProductsComponent care redă un tabel de elemente, citirea datelor dintr-un PRODUCTS_CATALOG constantă și oferind un buton „Adăugați în coș”. La clic, articolul rămâne în localStorage sub o cheie „coș”, incrementând cantitățile atunci când produsul există deja.

Microfrontend-ul căruciorului citește apoi din același localStorage cheie, afișează un tabel cu numele produsului, prețul, cantitatea și totalul și oferă un buton „Șterge coșul” care șterge memoria și resetează starea internă a acestuia. Aceasta este o modalitate simplă, dar ilustrativă, de a partaja starea între două aplicații independente, fără o cuplare strânsă.

Construirea shell-ului gazdă: aspect, pagină principală și navigare

O shell gazdă solidă este esențială pentru o experiență bună a utilizatorului pe microfrontend-uri.De obicei, deține aspectul global (antet, subsol, bare laterale), rutarea la nivel superior și uneori starea globală, cum ar fi autentificarea sau indicatoarele de caracteristici.

În exemplul Angular, gazda definește un LayoutComponent care redă un antet și un element imbricat router-outletAntetul își are propria existență HeaderModule și expune linkuri de navigare către pagina principală, lista de produse și coșul de cumpărături prin intermediul Angular routerLinkCăile de rută pot fi centralizate într-o enumerare precum RoutesPath pentru a evita șirurile magice.

Modulul de rutare a layout-ului configurează o rută părinte cu LayoutComponent ca și componentă a sa și definește rute copil pentru /home, /products și /cart. /home calea încarcă un local HomeModule; ceilalți folosesc loadRemoteModule pentru a extrage microfrontend-urile Angular în timpul execuției.

În cadrul gazdei, o SharedModule poate aduna blocuri de construcție reutilizabile cum ar fi antetul, aspectul, directivele comune și constantele. Acest modul poate fi importat în directorul rădăcină AppModule împreuna cu AppRoutingModule, care indică calea goală către configurația de rutare a machetei.

Next.js și microfrontend-uri

Next.js, ca framework React de nivel de producție, se potrivește bine și cu o abordare microfrontend., mai ales că a adoptat Webpack 5 și, prin urmare, suport pentru Module Federation. Concentrarea sa pe SSR, regenerarea statică incrementală și rutare îl face un bun candidat pentru shell, microfrontend-uri individuale sau ambele.

Pentru a implementa microfrontend-uri în Next.js, de obicei configurați Module Federation la nivel de Webpack., expunând anumite pagini sau componente ca remote și consumându-le de la o gazdă. Chiar dacă Module Federation este „doar” o caracteristică de grupare JavaScript, o puteți considera un model arhitectural: vă permite să încărcați dinamic cod deținut de diferite echipe fără a grupa totul împreună în prealabil.

Pentru versiunile vechi de Next.js fără Webpack 5, veți avea nevoie de adaptoare externe. pentru a activa suportul pentru federație. Începând cu Next 10.2, suportul pentru Webpack 5 este încorporat, ceea ce simplifică dramatic configurarea.

Single-SPA și alte framework-uri microfrontend

Single-SPA este o altă soluție binecunoscută pentru microfrontend-uri, în special în ecosistemele React.Se concentrează pe orchestrarea mai multor aplicații independente pe aceeași pagină, fiecare montată în propriul nod DOM pe baza rutei curente.

Cu Single-SPA poți avea mai multe aplicații React (sau chiar poți combina React, Vue, Angular) coexistând.Framework-ul gestionează momentul bootării, monturii sau demontării fiecărui microfrontend pe măsură ce utilizatorul navighează, iar tu îl integrezi în strategia ta de rutare (de exemplu, cu React Router în fiecare fragment).

Când alegeți între un singur SPA și federație de module, echipele își iau adesea în considerare preferințele privind pachetele/instrumentele. Module Federation se integrează profund cu Webpack (și, din ce în ce mai mult, cu alternative precum Rspack sau Rollup, pe măsură ce acestea adaugă suport). Single-SPA, pe de altă parte, se referă mai mult la orchestrarea în timpul execuției decât la partajarea pachetelor, astfel încât îl puteți utiliza cu diferite instrumente de compilare în timp ce gestionați partajarea codului în alte moduri.

Obiective, caracteristici și beneficii ale microfrontend-urilor

Obiectivul principal al microfrontend-urilor este de a scala dezvoltarea frontend-ului în cadrul mai multor echipe, fără a se prăbuși sub presiunea supraîncărcării coordonării.În loc de o bază de cod gigantică cu versiuni sincronizate, obțineți unități mai mici, implementabile independent.

Obiectivele cheie includ de obicei permițând mai multor echipe să lucreze în paralel, susținând implementarea independentă pentru diferite părți ale interfeței utilizator, menținând flexibilitatea de a utiliza diferite tehnologii acolo unde are sens și îmbunătățind mentenabilitatea prin reducerea dimensiunii și complexității fiecărei baze de cod.

Caracteristicile tipice ale unei astfel de arhitecturi sunt reutilizarea componentelor prin biblioteci partajate., integrare modulară prin intermediul unui shell de aplicație, conducte independente per microfrontend, optimizare a performanței prin CDN-uri și cache, gestionare centralizată a securității și observabilitate puternică.

Din perspectiva afacerilor, beneficiile sunt substanțialeDezvoltarea se scalează mai bine cu mai multe echipe, eșecurile sunt mai bine izolate, funcțiile pot fi implementate sau anulate per domeniu, iar stivele frontend vechi pot fi migrate treptat prin înlocuirea unei secțiuni pe rând, în loc să se rescrie întreaga aplicație.

Componente cheie într-o arhitectură microfrontend

Deși implementările variază, majoritatea arhitecturilor microfrontend au în comun câteva componente structurale. care mențin totul coerent.

Shell-ul aplicației (sau containerul) este coloana vertebralăDeține aspectul exterior, navigarea globală, autentificarea, uneori starea globală și logica pentru încărcarea sau descărcarea microfrontend-urilor. În configurațiile bazate pe browser, pagina este cea care extrage toate celelalte pachete.

Fiecare microfrontend este un modul autonom care implementează o capacitate specifică, cum ar fi catalogul de produse, coșul de cumpărături, profilul utilizatorului sau panoul de administrare. Expune o suprafață de integrare (rute, elemente personalizate, comenzi de federare a modulelor) și ascunde detaliile interne de restul sistemului.

Un magistral de evenimente sau un sistem de mesaje este adesea prezent pentru comunicarea între microfrontend.Aceasta poate fi o simplă abstracție asupra evenimentelor DOM, un depozit Redux centralizat sau un broker de mesaje personalizat. Scopul este semantica decuplată de publicare/abonare: un microfrontend emite evenimente fără a ști cine le gestionează.

Bibliotecile partajate găzduiesc componente reutilizabile ale interfeței utilizator, utilitare, token-uri de design și clienți comuniÎn configurațiile monorepo, instrumente precum Nx ies în evidență, permițându-vă să definiți pachete partajate consumate de mai multe aplicații cu limite impuse și versiuni consistente.

Colectori și instrumente de observabilitate (de exemplu, folosind OpenTelemetry) agregarea jurnalelor, a metricilor și a urmelor din toate microfrontend-urile, ceea ce face posibilă diagnosticarea problemelor care se întind pe mai multe fragmente sau servicii.

CDN-urile completează imaginea din partea de livrare, stocarea în cache a resurselor statice precum pachete JS, CSS și imagini în apropierea utilizatorilor, reducând latența și descărcând serverele de origine. În configurațiile microfrontend, adesea găzduiți resursele fiecărui fragment pe propria cale CDN pentru stocare în cache și implementări independente.

Arhitectură și modele de design pentru microfrontend-uri

Există un catalog bogat de modele care se aplică în mod specific microfrontend-urilor, de obicei definite de modul în care le compuneți, le implementați și le conectați.

Compoziția bazată pe componente înseamnă construirea interfeței utilizator din componente web sau primitive similare.Fiecare componentă are o singură responsabilitate, intrări și ieșiri clare și poate fi testată izolat. Un strat de compoziție de nivel superior (cum ar fi o shell sau un framework de orchestrare) aranjează aceste componente în pagini complete.

Modelul de federație pune accentul pe autonomia completă a aplicațiilorFiecare microfrontend este o aplicație independentă, cu propriul ciclu de viață și echipă; shell-ul sau un gateway API pur și simplu direcționează cererile/datele către fragmentul corect. Comunicarea se face prin API-uri sau evenimente REST bine definite.

Modelul shell al aplicației este practic abordarea „gazdă”Shell-ul încarcă microfrontend-uri, gestionează aspecte transversale precum navigarea și securitatea și asigură un aspect și o funcționalitate consecvente. Acest lucru este foarte comun în cazul configurațiilor bazate pe Module Federation sau Single-SPA.

Gateway-ul API și modelele Backend-for-Frontend (BFF) se concentrează pe partea de serverUn gateway API se află în fața multor servicii backend, direcționând cererile și aplicând securitate. Un BFF merge mai departe: fiecare frontend (web, mobil, IoT) poate avea propriul backend dedicat, adaptat nevoilor sale.

Modelele de stocare distribuită a datelor recunosc faptul că diferite microfrontend-uri își pot gestiona propriile surse de date sau cache-uri. În browser, aceasta înseamnă adesea utilizarea de chei localStorage separate, baze de date IndexedDB sau depozite în memorie, în timp ce în backend înseamnă baze de date separate per microserviciu.

Observabilitate, implementare independentă, scalabilitate orizontală și modele de securitate abordarea problemelor operaționale: cum să monitorizezi fiecare fragment, cum să le implementezi fără întreruperi globale, cum să le scalezi sub sarcină și cum să impui autentificarea/autorizarea în mod consecvent.

Compoziția rutării și modelele de încărcare lentă sunt esențiale pentru UX și performanțăUn router principal decide ce microfrontend gestionează ce cale, iar fiecare microfrontend are propriul router intern. Încărcarea lentă asigură descărcarea doar a codului pentru fragmentele necesare pentru ruta curentă.

În cele din urmă, modelele de comunicare bazate pe evenimente asigură că microfrontend-urile slab cuplate se pot coordona în continuare prin evenimente de domeniu, fără a introduce dependențe directe care ar anula ideea de modularitate.

Când să se utilizeze microfrontend-uri (și când nu)

Microfrontend-urile se remarcă în aplicații mari și complexe, cu domenii funcționale bine definiteGândiți-vă la platforme de comerț electronic, sisteme de management al întreprinderilor, portaluri municipale, platforme educaționale, portaluri mari de sănătate sau orice produs cu multe echipe care lucrează în domenii funcționale separate.

Sunt deosebit de utile atunci când aveți mai multe echipe care lucrează în paralel care necesită autonomie în alegerile tehnologice, ciclurile de lansare și prioritățile sau când modernizați lent un frontend vechi și nu vă puteți permite o rescriere completă. Puteți decupa câte o zonă pe rând într-un microfrontend nou și să îl integrați cu vechea shell.

De asemenea, sunt utile atunci când diferite părți ale aplicației trebuie să se scaleze diferit.O pagină de conectare sau de finalizare a comenzii ar putea primi mult mai mult trafic decât un ecran de configurare administrativă; scalarea independentă a acestor segmente poate economisi considerabil costuri de infrastructură.

Totuși, microfrontend-urile nu sunt o achiziție gratuită.Acestea adaugă complexitate arhitecturală, necesită o coordonare puternică în ceea ce privește experiența utilizatorului (UX) și contractele partajate și introduc noi moduri de eroare (de exemplu, un fragment nu se încarcă). Pentru aplicațiile mici sau mijlocii cu o singură echipă, un monolit bine structurat este adesea mai simplu și mai rentabil.

Echipele ar trebui să fie, de asemenea, precaute cu „anarhia cadrului de lucru”.Deși este posibil din punct de vedere tehnic ca fiecare microfrontend să utilizeze un stack complet diferit, un amestec necontrolat de framework-uri îngreunează angajarea, instrumentarea și partajarea codului. Un nivel rezonabil de aliniere (de exemplu, „suntem un magazin React-first, dar permitem Angular pentru anumite domenii”) funcționează de obicei mai bine pe termen lung.

Microfrontend-urile extind mentalitatea microserviciilor la nivelul browserului, oferind echipelor o modalitate de a împărți frontend-urile mari în componente autonome, orientate spre domeniu, care pot evolua, implementa și scala independent, formând în același timp o experiență coerentă pentru utilizator atunci când sunt combinate printr-un shell de aplicație, biblioteci partajate, federație de module, componente web sau framework-uri de orchestrare precum Single-SPA.