Cuprins[Ascunde][Spectacol]
- Introducere în arhitectura micro-front-end
Avantajele Micro frontend +-
- Dezvoltare în echipe rapid autonome
- Bazele de cod mai mici ale micro-frontend-urilor individuale duc la un cod mai curat
- Stabilitate îmbunătățită a aplicației din cauza unui cuplaj liber
- Testarea caracteristicilor individuale este simplificată
- Dimensiunea redusă a pachetului duce la o încărcare mai rapidă a paginii
- Independența Tehnologică
- Concluzie
Ideea de microservicii a câștigat multă atenție recent și multe firme o folosesc pentru a elimina backend-urile mari, monolitice.
A merge pe aceeași cale cu front-end-ul este încă o provocare pentru multe companii, chiar dacă acest mod distribuit de a construi partea de server a aplicațiilor web este mai mult sau mai puțin fiabil în ceea ce privește cercetarea și execuția.
Datorită dependenței sale strânse, monolitul de pe partea clientului face de obicei dificilă integrarea de noi funcții, adoptarea de noi tehnologii și scalarea componentelor individuale.
Acestea și alte provocări i-au determinat pe dezvoltatorii de front-end să investigheze utilizarea microserviciilor.
Ca rezultat, a fost dezvoltată o strategie arhitecturală nou-nouță, cunoscută sub numele de micro frontend, pentru a crea stratul front-end de site-uri web și aplicații bazate pe web.
Termenul a fost folosit pentru prima dată în 2016 și, de atunci, a atras multă atenție pentru o cauză bună.
Acest articol va oferi o înțelegere generală a ceea ce sunt micro frontend-urile și problemele pe care le abordează. funcționează, precum și argumente pro și contra.
Introducere în arhitectura micro-front-end
O metodă contemporană de dezvoltare front-end numită arhitectură micro-frontend împarte a aplicatie web în părți mici, independente.
Pentru utilizatorul final, aceste părți par a fi o singură unitate, chiar dacă au fost construite independent și apoi puse împreună.
Cu diferența că micro frontend-urile se referă la partea client, nu la partea serverului, a soluțiilor online, rațiunea care stă la baza acestora este identică cu cea a microserviciilor.
Realizarea de produse sofisticate bazate pe web are cel mai mult sens atunci când utilizați o abordare micro-frontend.
Micro frontend-urile, spre deosebire de un monolit front-end mai convențional, permit multor echipe să colaboreze separat la diferite proiecte software.
Programatorii pot crea aplicații web mai rapid și cu o scalabilitate și o întreținere mai mari folosind acest design arhitectural.
Pentru a spune simplu, fiecare micro frontend este doar o bucată de cod pentru o componentă distinctă a paginii web.
Aceste caracteristici sunt controlate de echipe separate, fiecare fiind specializată într-o anumită industrie sau obiectiv.
Arhitectură monolitică vs microservicii vs micro frontend
Gândiți-vă la mutare. Vă va fi mai simplu să organizați totul într-un număr de cutii mici, etichetate expert și să le mutați pe fiecare individual sau să împachetați întregul personal într-o cutie enormă și să-l transportați într-o locație nouă?
Soluția evidentă este acolo.
Această analogie compară cele două arhitecturi distincte de aplicații web, monoliți și microservicii (cunoscute și sub denumirea de micro frontend-uri).
Arhitectura monolitică
S-ar putea să vă amintiți „vremurile bune” când a fost creată o aplicație completă ca o entitate unică, coerentă. O astfel de metodă se numește monolit, care este un termen vechi pentru un bloc mare de piatră.
Are sens.
Sistemele monolitice au elemente interdependente. Prin urmare, dacă doriți să modificați ceva sau să adăugați o funcție nouă, este posibil ca întregul sistem să se defecteze.
Chiar dacă este învechit, ocazional încă există. Da, suntem conștienți de expresia dvs. actuală.
Împărțirea conceptuală a bazei de cod în două componente diferite - frontend (partea client) și backend (partea server) - a devenit inevitabilă pe măsură ce noile tehnologii dezvoltate și produsele software s-au complicat.
Cea mai populară metodă de operare este acum separarea preocupărilor între stratul de prezentare cu care interacționează un utilizator final și tot ceea ce are loc în fundal.
Are nevoie de două echipe de inginerie software, echipa front-end construind componentele vizuale și echipa back-end construind serviciile web, logica de afaceri, accesul la date, integrările etc.
Cu toate acestea, în ciuda acestei separări, această strategie rămâne încă monolitică prin natură.
Principala schimbare este că acum avem două blocuri de cod considerabile — front-end și backend — în loc de o aplicație enormă. Arhitecturile monolitice nu trebuie să fie teribile; au câteva beneficii, inclusiv
- Dezvoltare simplă și rapidă pentru aplicații minuscule cu o singură bază de cod sursă și un design foarte simplu;
- Testarea și depanarea sunt foarte simple, deoarece tot codul este într-o singură locație, ceea ce face mai ușor pentru o echipă să urmărească fluxul unei cereri și să identifice erori;
- La începutul dezvoltării unei aplicații, cheltuielile sunt mai ieftine, deoarece nici costurile de infrastructură, nici costurile de dezvoltare nu sunt suportate până când sunt adăugate noi caracteristici.
Dezavantajele acestei strategii se reflectă în
- Flexibilitate de implementare restricționată – echipele trebuie să aștepte dacă sunt doar o mână de ele care lucrează la proiect și este necesară o nouă implementare de fiecare dată când actualizați codul;
- Adoptarea noilor tehnologii este o provocare, deoarece aceasta necesită rescrierea unei părți semnificative, dacă nu a întregului proiect.
- Când numărul de dezvoltatori crește, un sistem de cod devine strâns conectat, complicat și dificil de gestionat și de înțeles.
- Probleme organizaționale – fiecare membru al echipei trebuie să folosească aceeași versiune de biblioteci și să raporteze orice modificări dacă multe echipe lucrează la un proiect monolitic.
- Preocupări legate de scalabilitate – deoarece componentele proiectului sunt interconectate, scalarea lor separată prezintă dificultăți care au ca rezultat timpi de nefuncționare semnificativi și cheltuieli mai mari.
- Logica complexă a proiectului ar putea fi dificil de înțeles pentru noii membri ai echipei, mai ales dacă inginerii care au lucrat inițial la el nu mai sunt angajați.
Dezvoltarea microserviciilor și a rudelor lor apropiate și a micro-interface-urilor au abordat problemele primare ale sistemelor monolitice.
Arhitectura microservicii
Metoda arhitecturală cunoscută sub denumirea de microservicii permite crearea a mai multor componente sau servicii mai mici, care pot fi implementate în mod independent, care alcătuiesc un backend de aplicație.
Fiecare serviciu are propria bază de cod, conducte CI/CD, proceduri DevOps și procese pentru rularea lor.
Puteți vedea că echipa de backend monolitică este împărțită în echipe separate uitându-vă la imaginea de mai sus.
Fiecare se concentrează individual pe un aspect diferit al aplicației (cum ar fi serviciul de produs, serviciul de căutare și serviciul de plată).
Comunicarea între servicii are loc prin intermediul protocoalelor stabilite cunoscute sub numele de API, cum ar fi protocolul API REST ușor, care utilizează modele de cerere-răspuns sincrone.
O altă opțiune este să utilizați comunicarea asincronă utilizând software precum Kafka, care oferă structuri și evenimente de comunicare de publicare/abonare.
Microserviciile se integrează cu front-end printr-un backend pentru serviciul frontend (BFF) sau printr-un API Gateway prin rețea. BFF oferă un API personalizat pentru fiecare client, în timp ce API Gateway oferă un singur punct de acces pentru o colecție de microservicii.
Dar chiar și cu componentele backend autonome și toate avantajele pe care le oferă, frontend-ul este încă un monolit.
Prin urmare, aici sunt utile micro frontend-urile.
Arhitectură micro frontend-uri
Similar microserviciilor, în care componentele slab legate sunt gestionate de mai multe echipe, arhitectura micro frontend aplică conceptul browserului.
Aceste interfețe cu utilizatorul aplicațiilor web urmează această structură, care constă din componente oarecum autonome.
Echipele sunt create, de asemenea, pe nevoile clienților sau pe cazuri de utilizare, mai degrabă decât pe o anumită expertiză sau tehnologie.
În consecință, echipele sunt implicate în proiecte de microservicii și micro frontend.
- tăiate vertical - deoarece există dezvoltatori de front-end, experți în date, ingineri backend, ingineri QA etc. care lucrează și la același proiect, aceștia își creează caracteristicile din interfața cu utilizatorul la baze de date; și
- interfuncțional – fiecare membru al echipei își contribuie cu expertiza la grup.
Echipele pot, de asemenea, să aleagă stiva de tehnologie care se potrivește cel mai bine liniei lor specifice de activitate.
O echipă poate folosi React pentru a-și programa fragmentul. O altă echipă creează o nouă versiune Angular. Vue.js este un astfel de exemplu.
Micro frontend-urile sunt folosite împreună cu microservicii aferente pentru a rezolva problemele pe care echipele de dezvoltare le au de obicei cu monoliții. Strategia oferă următoarele avantaje.
- Libertatea tehnologiei: inginerii front-end pot alege cadre JavaScript alternative, medii de rulare și stive întregi de tehnologie, în funcție de nevoile companiei. Pe lângă arhitectura învechită, ar putea fi aplicat un cadru nou.
- Este posibil un grad mai mare de flexibilitate, deoarece fiecare micro-frontend este autonom și poate fi dezvoltat, testat, implementat și actualizat separat. Drept urmare, dacă o echipă lucrează la o caracteristică și a remediat o eroare, iar o altă echipă trebuie să adauge propria caracteristică, nu trebuie să aștepte ca prima echipă să își finalizeze sarcina.
- Echipe și sisteme autonome: Fiecare echipă de produs și, în consecință, fiecare caracteristică poate funcționa cu o dependență redusă de altele, ceea ce îi permite să continue să funcționeze chiar și atunci când componentele din apropiere nu sunt disponibile.
- Baze de cod multiple, mai mici: Fiecare dintre micro-frontend-urile va avea propria bază de cod mai mică, mai ușor de gestionat. Mai puțini oameni se vor concentra pe o anumită componentă a interfeței de utilizare, vor simplifica revizuirile codului și vor îmbunătăți organizarea generală.
- Scalare simplă a aplicației: Un alt beneficiu al micro-frontend-urilor este capacitatea de a scala fiecare caracteristică în mod individual. Spre deosebire de monoliți, în care întregul program trebuie să fie scalat de fiecare dată când se adaugă o nouă caracteristică, acest lucru face ca întregul proces să fie mai eficient atât din punct de vedere al timpului, cât și al banilor.
Cum funcționează micro frontend-ul?
După cum am afirmat anterior, echipele sunt organizate vertical în interiorul arhitecturii micro-frontend, ceea ce înseamnă că sunt separate prin cunoștințe de domeniu sau scop și sunt responsabile de la început până la sfârșit pentru un anumit produs.
Poate avea unul sau două microservicii de backend, precum și un frontend mic. Mai detaliat, să examinăm caracteristicile acestui element vizual, interacțiunile cu alte componente ale UI și încorporarea în pagina de pornire.
Un micro frontend poate fi
- o pagină întreagă (de exemplu, o pagină cu detalii despre produs) sau
- secțiuni ale paginii care pot fi utilizate de alte echipe, cum ar fi anteturile, subsolurile și barele de căutare.
Puteți împărți un site web mare în mai multe tipuri de pagini și puteți oferi fiecare tip unui anumit personal la care să lucreze.
Cu toate acestea, mai multe componente apar frecvent pe numeroase pagini, cum ar fi anteturi, subsoluri, blocuri de sugestii etc. Un bloc de sugestii, de exemplu, poate fi inclus pe o pagină de pornire, pe o pagină cu detalii despre produs sau chiar pe pagina de finalizare a achiziției.
În esență, echipele pot crea piese pe care alte echipe le pot folosi pe paginile lor.
Micro frontend-urile, totuși, pot fi implementate separat ca proiecte diferite, spre deosebire de componentele reutilizabile.
Toate acestea sună fantastic, dar pentru a crea o interfață unificată, paginile și fragmentele trebuie cumva combinate.
Acest lucru necesită integrare frontend, care poate fi realizată printr-o varietate de strategii, inclusiv rutare, compunere și comunicare (vezi graficul de mai sus).
Rutare
Când serviciul dintr-o pagină controlată de o echipă este necesar pentru a accesa o pagină deținută de o altă echipă, rutarea este utilă pentru integrarea la nivel de pagină.
Fiecare micro-frontend este tratat ca o aplicație cu o singură pagină. Link-uri HTML simple pot fi folosite pentru a oferi rutare.
Un utilizator poate obliga browserul să descarce marcajul țintă de pe un server și să înlocuiască pagina curentă cu una nouă făcând clic pe hyperlinkuri.
Shell-ul aplicației este strictul minim de HTML, CSS și JavaScript care alimentează o interfață de utilizare. Chiar dacă datele de conținut solicitate de la server sunt încă în așteptare, utilizatorul primește imediat o pagină afișată statică. Carcasa centrală a aplicației servește ca o aplicație părinte pentru aplicațiile cu o singură pagină create de diferitele echipe.
Indiferent de biblioteca sau cadrul care este utilizat, meta-cadrele permit fuziunea diferitelor pagini într-una singură.
Compoziție
Compoziția este procesul de aranjare a pieselor pentru a le potrivi în spațiile adecvate dintr-o pagină. În cele mai multe cazuri, echipa care implementează pagina nu preia imediat conținutul fragmentului.
În schimb, plasează un substituent sau un marcator acolo unde fragmentul ar trebui să fie în marcaj.
Folosind un alt proces de compunere, se realizează asamblarea finală. Compoziția poate fi împărțită în două categorii de bază: partea client și partea serverului.
Compoziția pe partea clientului: Browserul web este folosit pentru a crea și edita marcaj HTML. Fiecare micro-frontend are capacitatea de a modifica și de a afișa marcajul separat de restul paginii.
Componentele Web, de exemplu, vă permit să efectuați acest tip de construcție.
Planul este de a transforma fiecare fragment într-o componentă web care poate fi instalată independent ca fișier a.js, după care aplicațiile le pot încărca și reda în spațiile desemnate pentru ele în aspectul temei.
Componentele web depind de API-ul HTML și DOM, pe care alte framework-uri frontend le pot folosi, precum și de o metodă standard de trimitere și primire a datelor prin elemente de recuzită și evenimente.
Compoziție pe partea serverului: Cu acest design, piesele UI sunt combinate pe server, ceea ce are ca rezultat trimiterea unei pagini complet formate către partea clientului, accelerând încărcarea.
Asamblarea este adesea efectuată de un serviciu separat care se află între browserul web și serverele web. CDN este o instanță a serviciului (rețeaua de livrare a conținutului).
Puteți alege unul sau o combinație dintre cele două, în funcție de nevoile dvs.
Modele de comunicare micro frontend
Arhitectura micro-frontend funcționează cel mai bine atunci când există puțină sau deloc interacțiune între diferitele componente. Micro frontend-urile trebuie ocazional să vorbească între ele și să partajeze informații. Iată câteva modele potențiale care ar putea duce la asta.
- Lucrători web: Un lucrător online este un mecanism care permite conținutului web să ruleze JavaScript în fundal, independent de alte scripturi și fără a afecta viteza paginii. Pentru fiecare microaplicație va fi furnizat un API unic de lucru. Acest avantaj este că munca consumatoare de timp poate fi efectuată într-un fir diferit, permițând firului de execuție UI să continue fără a fi încetinit sau oprit.
- Emițător de evenimente: În acest caz, multe componente comunică între ele ascultând și acționând asupra oricăror modificări de stare a componentelor la care sunt abonate. Alte micro-interface-uri care s-au abonat la acel eveniment specific răspund atunci când un micro-front-end declanșează acel eveniment. Un emițător de evenimente care a fost introdus în fiecare micro-frontend face acest lucru fezabil.
- Apeluri și recuzită: În această secțiune, definiți o componentă părinte și componente secundare. Comunicarea este organizată într-o structură arborescentă. Componentele părinte folosesc elemente de recuzită pentru a transmite datele ca funcții în arborele componente către componentele secundare. La rândul său, copilul poate alerta eficient părintele atunci când se întâmplă ceva în starea lor, răspunzând la apeluri inverse. React folosește acest mod.
Avantajele Micro frontend
Dezvoltare în echipe rapid autonome
O echipă independentă poate crea fiecare parte a unei aplicații web sau a unui site web atunci când folosește o metodă micro-frontend.
Fiecare echipă este complet autonomă, ceea ce înseamnă că este responsabilă de întregul ciclu de dezvoltare a componentelor, de la concepție până la lansare și post-producție.
În plus, implică faptul că diferite echipe pot colabora fără probleme în timp ce lucrează simultan la același proiect.
Prin urmare, ciclurile de eliberare sunt substanțial mai rapide decât ar fi cu monoliții front-end.
Bazele de cod mai mici ale micro-frontend-urilor individuale duc la un cod mai curat
Front-end-urile monolitice au baze de cod mari, greoaie, care devin din ce în ce mai haotice și dificil de gestionat în timp.
Micro frontend-urile abordează această problemă. Codul sursă al fiecărui micro frontend este mai ușor de gestionat, deoarece este mai mic, mai simplu și mai compact.
Soluția web generală beneficiază de un cod mai curat ca o consecință.
Stabilitate îmbunătățită a aplicației din cauza unui cuplaj liber
O soluție web poate fi rareori împărțită în bucăți complet independente. În consecință, micro frontend-urile vorbesc între ele.
Cu toate acestea, fiecare legătură între componente este semnificativă, în ciuda conectivității slabe.
Eșecul unei componente are un efect redus sau deloc asupra funcționării tuturor celorlalte componente, ceea ce asigură stabilitatea îmbunătățită a unei soluții web.
Testarea caracteristicilor individuale este simplificată
Acest beneficiu rezultă din caracteristicile micro frontend-urilor. Pe baza acestui design arhitectural, partea client a unei soluții web este modulară și fiecare modul este autonom.
Ca rezultat, evaluarea unei mici părți a interfeței cu utilizatorul este mai ușor de făcut pentru o echipă decât testarea unui monolit masiv.
Dimensiunea redusă a pachetului duce la o încărcare mai rapidă a paginii
Una dintre cauzele principale ale timpilor de încărcare întârziați în sistemele web monolitice bogate în funcții este dimensiunea unui pachet JavaScript. Pe de altă parte, o abordare micro-frontend facilitează reducerea timpului de încărcare a paginii.
Un browser nu trebuie să descarce cod inutil în mod repetat, deoarece o pagină web este alcătuită din mai multe pachete minuscule. Ca rezultat, performanța paginii și timpii de încărcare cresc.
Independența Tehnologică
Multiplu cadre front-end poate fi folosit de dezvoltatori pentru a crea o singură soluție online cu o arhitectură micro-frontend.
Deoarece fiecare componentă este autonomă, poate fi construită folosind tehnologia care se potrivește cel mai bine sarcinilor echipei.
Desigur, programatorii ar trebui să fie precauți atunci când selectează cadrele pentru proiectul software de care sunt responsabil, iar consultările cu alte echipe sunt în continuare recomandate.
Cu toate acestea, nu există nicio șansă să fiți forțat să utilizați un cadru moștenit pe toată durata de viață a aplicației.
Dezavantajele Micro Frontend-ului
Testarea complexă a soluțiilor Web în întregime
Testarea diferitelor module ale unei soluții web este ușoară atunci când folosește o arhitectură micro-frontend. Totuși, diferă de evaluarea unei aplicații web ca întreg.
Verificați dacă toate piesele funcționează așa cum este prevăzut înainte de a continua. Acest lucru ar putea fi dificil, deoarece micro frontend-urile funcționează independent și au procese de livrare separate.
Investiții inițiale costisitoare
Dezvoltarile micro-frontend necesită de obicei cheltuieli financiare substanțiale. Este costisitor să asamblați și să mențineți multe echipe de front-end.
În plus, veți avea nevoie de personal de management pentru a organiza munca, a vă asigura că totul este coordonat și a garanta o comunicare excelentă în echipă.
Complexitatea dezvoltării și implementării
Procedurile de dezvoltare și implementare pot deveni mai complicate ca urmare a unui design micro-frontend.
O soluție ar putea fi aglomerată cu prea multe componente de către echipele de dezvoltare independente care lucrează la același proiect, de exemplu, ceea ce ar putea cauza probleme în etapa de implementare.
Asamblarea corectă a tuturor modulelor și integrarea lor fără probleme în schema generală nu este, de asemenea, întotdeauna simplă; această muncă necesită de obicei o înțelegere aprofundată a tuturor dependențelor.
Probleme de menținere a coerenței în experiența utilizatorului
Menținerea unei interfețe de utilizator consistentă este o provocare atunci când echipele lucrează separat pe mai multe părți ale software-ului.
Soluția web ar trebui să fie partajată de toți dezvoltatorii proiectului. În caz contrar, pot exista o mulțime de contradicții de-a lungul drumului.
Concluzie
Micro frontend-urile, un design arhitectural contemporan, pot îmbunătăți considerabil performanța proiectelor de dezvoltare web la scară largă bazate pe microservicii.
Le permite programatorilor să împartă soluția completă în părți discrete care pot fi create de mai multe echipe autonome. De aici rezultă numeroase beneficii, inclusiv lansarea mai rapidă a funcțiilor, testarea mai ușoară a modulelor individuale și upgrade-uri mai simple.
Dar există unele dificultăți și cu micro-frontend-urile.
Testarea cuprinzătoare a unei aplicații, de exemplu, ar putea fi o provocare.
În plus, deoarece este nevoie de o echipă mare de ingineri și administratori, proiectele micro-frontend sunt foarte costisitoare.
În consecință, înainte de a lua o decizie, trebuie să ții cont de toate componentele business-ului tău.
Vladimír Čamaj
Cumva nu am înțeles pe ce principiu funcționează comunicarea între componentele individuale de pe front-end. Nu înțeleg cum doriți să conectați componente care sunt create în cadre diferite. Nu există nimic în articol despre asta. Sistemul de evenimente și ascultători mi se pare un iad pe pământ. Cum ar trebui să ne imaginăm?