Smashing Podcast Episodul 6 Cu Luca Mezzalira: Ce sunt micro-frontend-urile?

Încheiem anul acesta cu încă un podcast Smashing! De data aceasta, vom vorbi despre micro-frontend-uri. Ce este un micro-frontend? Cum este diferit de felul de abordare pe care am putea-o adopta în acest moment? Să aflăm de la pionierul micro-frontend, Luca Mezzalira.

Afișați note

Actualizare săptămânală

• „Adăugarea de funcționalități dinamice și asincrone la site-urile JAMstack”, Jason Lengstorf
• „Instrumente de date cantitative pentru designeri UX”, Adonis Raduca
• „Crearea abilităților vocale pentru Google Assistant și Amazon Alexa”, Tris Tolliday
• „Dincolo de Sprint 0: o alternativă pentru integrarea echipelor”, Shamsi Brinn
• „Ajutând browserele să optimizeze cu proprietatea CSS Contain”, Rachel Andrew

Micro-Frontend-uri

• Site-ul lui Luca Mezzalira
• Luca pe Twitter
• „Micro-Frontend-uri, viitorul arhitecturilor frontale” pe mediu
• Mai multe din scrierile lui Luca despre micro-frontend-uri pot fi găsite pe contul său Medium
• Cartea lui Luca „Front-End Reactive Architectures”

Transcriere

Drew McLellan: Este un dezvoltator Google expert în tehnologii web și manager al comunității JavaScript din Londra. Cu o experiență de peste 15 ani, el lucrează în prezent ca VP de Arhitectură, proiectând platforma video sportivă DAZN, care oferă conținut sportiv la cerere pentru milioane de utilizatori care vizionează în direct. El este autorul cărții Front-End Reactive Architectures pentru Apress și este, de asemenea, recenzent tehnic pentru Apress, Packt Publishing, Pragmatic Bookshelf și O'Reilly, precum și un vorbitor public cu experiență la conferințe tehnice din întreaga lume. Este italian, are o barbă frumoasă și are în mod clar cunoștințe profunde despre platforma web. Dar știai că a traversat odată America de Sud pe un struț? Prietenii mei zdrobitori, vă rog bun venit lui Luca Mezzalira. Salut, Luca. Ce mai faci?

Luca Mezzalira: Sunt zdrobitor.

Drew: Vreau să vă vorbesc astăzi despre subiectul micro-frontend-urilor. Acum, acesta este un concept complet nou pentru mine, cu siguranță după nume și mă aștept să fie nou și pentru mulți dintre ascultătorii noștri. Înainte de a intra în micro-frontend-urile în sine, cred că ar trebui să înțelegem problema pe care doriți să o rezolvați cu ele. Așadar, poate ne-ați putea spune puțin despre cum vedeți aplicațiile într-un mod mai tradițional și despre ce fel de probleme se confruntă cu acele lucruri la care poate micro-frontend-urile ar putea fi soluția?

Luca: Bine, acesta este un bun punct de plecare, după părerea mea. Deci, de obicei, atunci când implementați sau proiectați un nou proiect green field și doriți să lucrați cu aplicații front-end, aveți câteva arhitecturi pe care le puteți folosi. Puteți folosi o aplicație cu o singură pagină, puteți utiliza o aplicație de randare pe partea serverului sau puteți utiliza o aplicație cu mai multe pagini compusă doar din simple pagini HTML. Evident, acestea sunt opțiuni super valide și cred că sunt foarte folosite de mulți, mulți dezvoltatori. Adevărata problemă pe care încercăm să o rezolvăm aici este cum puteți scala aceste concepte cu echipe distribuite la sute de dezvoltatori care lucrează pe aceeași bază de cod, pentru că realitatea este atunci când lucrați în aceste platforme în special, când vă gândiți la Platforma SaaS, de exemplu, trebuie să aveți mai mulți dezvoltatori și mai multe echipe care lucrează la același proiect. Și, evident, modul în care, de exemplu, faceți achiziție sau reținere este complet diferit de modul în care expuneți catalogul sau de modul în care afișați o anumită parte a unei platforme.

Luca: Așa că acum, din experiența mea, lucrez mult cu aplicația pe o singură pagină. Lucrez cu o aplicație de randare pe server, dar la un moment dat în DAZN mi se va cere să mă gândesc la o modalitate de a mări echipa noastră tehnică. Și trebuie să vin... dacă pentru backend avem o soluție care sunt microservicii în acest caz, astfel încât să ne putem scala API-urile în mod independent și să luăm în considerare scara și volumul pentru un anumit debit pe un anumit API. Pe front-end, într-adevăr, este cu adevărat mai dificil pentru că, dacă te gândești la asta, nu ai probleme tehnice de rezolvat atunci când trebuie să scalați, dacă utilizați o aplicație cu o singură pagină, de exemplu. Probabil că pentru o randare pe partea de server aveți unele, dar pe o aplicație cu o singură pagină, de exemplu, este distribuită prin natura, deoarece este pe partea clientului, diferită pe partea clientului.

Luca: Deci singurul lucru pe care îl încarcă sunt doar niște fișiere statice precum CSS și HTML și JavaScript care sunt servite de CDN și, în acest caz, puteți scala în consecință, nu este o mare provocare. Dar adevărata provocare este modul în care scalați echipele care lucrează pe aceeași platformă, pentru că uneori provocările cu care se confruntă o echipă pot fi complet diferite de provocările cu care se confruntă o altă echipă și, de obicei, ceea ce faci este să încerci să găsești. multe compromisuri între lucruri. Pentru că dacă te gândești, hai să încercăm să ne gândim la un caz normal de utilizare. Deci, de obicei, atunci când porniți o platformă, începeți cu puțin. Așa că încerci să creezi acea aplicație rapidă de o singură pagină, de asemenea, ai monolitul tău, așa că ai configurat totul în CICD o singură dată pentru front-end și back-end și apoi începi să iterați logica. Dar realitatea este că atunci când ai succes, trebuie să evoluezi această parte și nu este menținerea întotdeauna aceeași arhitectură care ar putea, să spunem, să creeze beneficii pentru afacerea ta, pentru că poate poți găsi niște blocaje.

Luca: Așa că revenim la partea aplicației cu o singură pagină. Deci, dacă vrem să scalam o parte de aplicație de o singură pagină, provocarea nu este tehnică, ci este cu oameni dacă doriți. Deci, cum putem scala echipele care lucrează la aceeași aplicație. Deci, ceea ce am făcut acum câțiva ani a fost începutul să mă uit la o posibilă arhitectură și la principii care să-mi permită să măresc atât front-end-ul, cât și backend-ul. Deci, lucrând la principiile backend, astfel încât să puteți găsi microservicii. Am început să mă uit la soluția diferită și au ieșit cu micro-frontend-urile pe care la început nici nu le spuneam așa, pentru că evident că de ani în urmă nu exista, să spunem, acel nume pentru acea arhitectură specifică. .

Luca: Dar realitatea este să ia un monolit, deci o aplicație pe o singură pagină și să o tăiem într-un mod care să ne permită să ne concentrăm asupra unei mici probleme. Deci o problemă mai mică decât întreaga aplicație și încercând să o rezolvăm în cel mai bun mod posibil. Tehnic vorbind. Evident, acest lucru duce la existența unor piese independente din aplicația dvs. frontală care ar putea fi implementate în producție fără a le afecta pe toate celelalte. Așa că, în principiu, provocarea pentru Micro-frontend este să încerce să-și dea seama de a lua o singură pagină de aplicație sau de o aplicație randată pe partea de server și de a crea un artefact din acestea, să spunem, cât mai aproape posibil de un domeniu de afaceri și poate fi implementat independent. .

Drew: Adică ați menționat micro-servicii în spate. Deci, din punct de vedere conceptual, aceasta este un tip similar de soluție la problemă. Microserviciile servesc pe partea din spate, dar sunt portate pe partea din față. Este o echivalență aproximativă sau este mai implicată în asta?

Luca: Da. Nu, este o modalitate de a rezolva aceeași problemă în care încearcă să rezolve microservicii pe back-end, dar pe front-end în acest timp. De obicei, când am început această călătorie la început, știi, începi să te gândești la asta și începi să evaluezi diferite abordări. Și în ultimele luni am venit cu ceea ce ei numesc, cadru de decizie Micro-frontend, care este practic patru pași pe care îi folosesc pentru a, să presupunem că identificați o abordare pentru Micro-frontend, pentru că dacă până acum, noi de obicei alegem un cadru care a proiectat arhitectura pentru noi și implementăm pe deasupra arhitecturii lor. Dacă te gândești la angular sau te gândești la React sau Redux. Ai toate piesele necesare dar nu iei decizii arhitecturale. Veți lua decizii de proiectare sau cum să implementați pe deasupra acelei arhitecturi specifice.

Luca: Deci, pe Micro-frontend, trebuie să începeți pasul înapoi. Așa că trebuie să ne gândim cum vrem să ne feliem mai întâi aplicația. Deci, de obicei, există două opțiuni pentru asta. Puteți tăia orizontal, astfel încât să aveți mai multe micro-frontend-uri în aceeași vizualizare sau puteți tăia pe verticală. Prin urmare, încărcați întotdeauna un Micro-frontend de fiecare dată. Și aceste decizii sunt destul de esențiale, deoarece apoi vor casca anumite alte opțiuni pe care le aveți pe baza deciziei inițiale de luat. Așa că primul, așa cum am spus, decideți cum doriți să tăiați aplicația. Al doilea este modul în care doriți să compuneți aplicația. Deci, doriți să aveți, de exemplu, un shell de aplicație care încarcă unul sau mai multe micro-frontend-uri în aceeași vizualizare. Vrei să ai, nu știu, un server de aplicații care compune diferite fragmente ale aplicațiilor tale, deci un Micro-frontend diferit și apoi să ofere vizualizarea finală utilizatorului tău. Sau doriți să utilizați marginea inclusă, este un standard care se află în interiorul CDN-urilor pentru a compune o pagină și a le difuza acolo.

Luca: Acestea sunt trei dintre opțiunile pe care le ai. Și apoi, în afară de a compune, atunci trebuie să te gândești cum vrei să mergi. Deci, cum rutați de la, nu știu, /login sau /signin către partea de catalog sau un anumit obiect de detaliu. De asemenea, aici aveți trei opțiuni. O poți face la serverul de aplicații, o poți face la nivel CDN cu Lambda Edge sau orice alt lucrător web din CloudFlare sau orice altceva. Sau puteți face un site client. Deci, aveți o logică în interiorul shell-ului aplicației pe care spuneți, bine, acum, pentru această adresă URL specifică, trebuie să încărcați o altă vizualizare sau un alt micro-frontend. Și ultimul fragment este modul în care comunicați cu Micro-frontend.

Luca: Deci, de obicei, dacă aveți like-uri multiple Micro-frontend pe aceeași pagină, există o complexitate mai mare în gestionarea acestei comunicări, deoarece trebuie să mențineți diferitele Micro-frontend independente. Deci, asta înseamnă că nu poți avea nicio referință despre modul în care este structurată pagina. Deci, de obicei, puteți utiliza lucruri precum evenimente personalizate sau un contor de evenimente care este injectat în fiecare Micro-frontend. Și apoi Micro-frontend comunică împreună. Evident, în celălalt caz, atunci când aveți ca să spunem că o despărțire verticală a Micro-frontend-ului dvs. este mult mai ușoară, deoarece în interiorul vertical, în principiu, reprezentarea unui Micro-frontend vertical este o aplicație cu o singură pagină sau o singură pagină. Și în acest caz, este mai ușor să spunem să creăm și să partajați având o stare partajată în întregul Micro-frontend.

Luca: Atunci, dacă te gândești să ai mai multe Micro-frontend împreună, atunci ar trebui să evitați să aveți stări care sunt partajate pe Micro-frontend, pentru că altfel cuplați lucrurile. În loc de întregul concept, aici este decuplarea și implementarea independentă. Și, prin urmare, să presupunem că provocările unei divizări orizontale, care este prima decizie pe care ar trebui să o luați sau a unei divizări pe verticală, sunt complet diferite și trebuie să fim foarte conștienți care dintre ele se potrivește cazului nostru de utilizare.

Drew: Deci, mai degrabă decât o soluție tehnică specifică, micro frontend-urile sunt foarte asemănătoare unui model de design pe care l-ați implementa în orice tehnologie este potrivită pentru problema particulară pe care încercați să o rezolvați?

Luca: Da, mai mult decât tehnologie, aș vedea că alegem arhitectura potrivită pentru jobul potrivit. Doar ca să vă dau un exemplu, vorbeam... există un framework faimos, un framework destul de nou pentru Micro-frontend, se numește Luigi framework, care a fost lansat de SAP open source. Ceea ce fac ei este să creeze niște cadre iframe în care își împachetează Micro-frontend-ul în interiorul acestuia. Deci, acum, dacă te gândești la asta, să spunem, folosind iframe în zilele noastre, te afli pe un site web public care poate ca SEO sau alte caracteristici care sunt obligatorii, ar putea fi problematic.

Luca: Dar în cazul SAP, dacă te gândești la asta, au o aplicație de tip enterprise unde pot controla browserul pe care îl folosește utilizatorul, pot controla mediul, nu trebuie să fie disponibili într-o multitudine sau versiune diferită a browserului. Deci pentru ei acest lucru le permite să aibă anumite zone ale aplicației care sunt constante și au anumite zone care se schimbă independent fără nicio problemă. Dar, evident, o soluție iframe nu ar funcționa în altă situație. Doar pentru a da un alt exemplu, Spotify, folosim iframe la început. De fapt, publicația de birou este încă compusă din mai multe iframe și fiecare iframe este o aplicație minusculă care face, nu știu, doar un music player sau doar recomandarea lor, oricare ar fi ea. Ei încearcă să aibă aceeași abordare pe web, dar au respins asta anul acesta pentru a reveni la o aplicație pe o singură pagină.

Luca: Și asta înseamnă că ei explică de ce în blogul tehnic, ei spuneau că, evident, dacă aplici asta la milioane de utilizatori care folosesc iframe, trebuie să se încarce de fiecare dată același fișier de furnizori. Și atunci aveți o mulțime de dependențe duplicate și timpul de interacțiune cu pagina dvs. ar fi mai lung. Deci, în realitate, această abordare s-ar putea potrivi pentru anumite cazuri de utilizare, dar nu ar trebui să se potrivească pentru toate. De aceea spun, așa cum am descris mai înainte, dacă aveți un cadru de decizie care vă ajută să abordați aceste lucruri și puteți începe să spuneți, bine, am tăiat aplicația în acest fel, prin urmare am acele opțiuni care sunt disponibile cand vreau sa compun, cand vreau sa fac traseu, cand vreau sa comunic, ar trebui sa te ghideze pentru a avea decizia corecta la momentul potrivit.

Luca: Atunci, evident, în afară de acele patru decizii, mai sunt multe altele. La fel cum creați consecvență în sistemul de design pe care îl aveți în toate Micro-frontend-ul. Sau nu știu cum gestionați dependențele și evitați ciocnirea dependenței în interiorul Micro-frontend-ului, dar realitatea este că acele patru decizii pe care le-am menționat mai înainte vă vor permite să le luați apoi pe toate celelalte într-un mod rapid fără a avea problema supragândirii, care este cea mai bună soluție pentru că ai pus deja piatra de temelie, cei patru piloni, care îți vor permite să iei toate celelalte decizii… nu spun într-un mod ușor, ci într-un mod mai rapid decât un review sau spectrul de oportunități.

Drew: Ați menționat mai devreme modul în care Micro-frontend poate ajuta cu genul de structură a echipelor din cadrul organizației dvs. și cu mulți oameni care lucrează la aceeași aplicație. Care sunt unele dintre implicații atunci și are vreo diferență dacă echipele dvs. sunt distribuite sau colocate sau există provocări cu care se confruntă acolo?

Luca: Da. Așa că vă pot spune care este povestea lui DAZN. Aceasta este compania la care lucrez. Momentan în DAZN, am avut ca o provocare frumoasă. Deci, în prezent avem peste 300 de oameni care lucrează în partea din față și în spatele platformei noastre. Este o platformă OTT care transmite live la evenimente sportive la nivel global. Și partea interesantă este dacă toate microserviciile știm să gestionăm mai mult sau mai puțin și avem echipe distribuite. Deci avem patru centre de dezvoltare. Am vrea să punem echipe în fiecare centru de dezvoltare în față și am încercat această abordare și funcționează destul de bine. Așadar, cu Micro-frontend, am putut să oferim diferite domenii de afaceri în diferite locații și să permitem comunicarea încrucișată între echipe din interiorul unui anumit domeniu de afaceri, tocmai pentru că în cel mai rău caz acolo, dacă trebuie să vorbiți cu o altă echipă din același domeniu de afaceri , ajungeți doar la distanța de mers pe jos de la birou. Dacă, în schimb, trebuie să discutați ceva anume în echipa de distribuție, deci poate cu cineva din Londra în loc de Amsterdam, sau în loc de o companie din Polonia, trebuie doar să organizați un apel.

Luca: Dar aceste tipuri de comunicare sunt mai rare decât cele care au loc între echipe în aceeași locație. Și de aceea am început să lucrăm la asta. Deci, primul lucru pe care l-au făcut a fost să se uite cum interacționau utilizatorii noștri cu site-ul nostru web, cum a fost structurată compania. Și când identificăm cele patru domenii cheie la care lucrăm, care sunt în prezent achiziția și păstrarea, să spunem portarea aplicației lor de bază pe mai multe televizoare și dispozitive mobile și având domeniul de bază care pentru noi este playerul video și faza de descoperire a continutul nostru. Și în sfârșit toate elementele de back office. Am reușit să identific acele patru zone și noi acele patru zone pe care le-am atribuit fiecărui centru de dezvoltare.

Luca: Evident că există anumite puncte de contact între acele zone, dar apoi există modalități prin care poți să spunem să atenuezi și să organizezi un atelier inițial cu diferite echipe care se află în locații diferite și apoi să lucrezi la același contract API, de exemplu, sau același scop cu a avea unele puncte de control în timpul dezvoltării. Dar lucrul frumos al abordării care a permis abordarea cu Micro-frontend este faptul că în sfârșit înțelegem profund cum funcționează sistemul nostru. Ne așezăm și analizăm modul în care am fost structurați și am schimbat nu doar modul în care am fost afectați lucrurile, ci și modul în care funcționa compania. Și asta a fost un fel de abordare diferită de ceea ce au văzut până acum. Dar se dovedește că funcționează destul de bine în cazul în care fiecare echipă poate interacționa cu echipa din aceeași locație din același domeniu.

Luca: Deci, ei vorbesc exact pe aceeași limbă dacă vorbiți despre designul bazat pe domeniu. Și asta înseamnă că, dacă au nevoie să interacționeze cu alte echipe, pot împărtăși literalmente atelierul sau pot zbura la alt centru de dezvoltare și este mai puțin decât o problemă. Dar, în acest fel, să spunem, creștem debitul și reducem supraîncărcarea de comunicare și amploarea dependențelor care se întâmplau în altă situație la care lucrau.

Drew: Și toate aceste echipe trebuie să folosească ca un cadru JavaScript standardizat? Toate trebuie să codifice în aceleași lucruri, toate trebuie să fie fie React, fie Angular sau să permită interoperabilitatea între ele sau pot fi oamenii să folosească lucruri diferite pentru diferite Micro-frontend?

Luca: Da. Așa că în DAZN am decis să tăiem pe verticală Micro-frontend-ul nostru și aceasta a fost o decizie care ne-a permis să avem libertatea de a alege tehnologia de care avem nevoie pentru fiecare Micro-frontend. Având în vedere că de fiecare dată când încărcăm câte un Micro-frontend de fiecare dată și asta înseamnă că, de exemplu, modul în care avem o pagină de destinație este diferit de călătoria de conectare / înscriere. Așa că putem actualiza... folosim în principal React în acest moment. Dar dacă, de exemplu, îmi amintesc când React 16 a fost o lansare pe care am putut să o lansăm în producție React 16, de asemenea, dacă nu era în versiunea stabilă doar pentru o pagină de destinație și să văd dacă funcționa fără a afecta toate alte echipe.

Luca: Și apoi, în viteza lor, în ritmul lor, își actualizau propriile lucruri. Deci asta ne permite și să spunem să încercăm noi tehnologii sau noi ipoteze pe care le avem asupra aplicației existente cu un anumit număr de utilizatori. Pentru că implementăm și versiunile candidate pentru front-end. Implementăm, să spunem, mai multe practici care ne permit doar să încercăm anumite momente în producție și să vedem cum funcționează lucrurile.

Luca: Frumusețea acestor abordări este faptul că putem decide în mod independent să avem instrumentul potrivit pentru locul de muncă potrivit, mai mult decât să avem un numitor comun în întreaga stivă. Pentru că, după cum vă puteți imagina, atunci când ați început să lucrați la un proiect, decizia pe care ați luat-o în primii ani este probabil diferită de decizia pe care ați luat-o într-o traiectorie în care compania crește, afacerea evoluează și acestea au devenit mai mature. iar provocarea este cu totul alta. Deci nu ar fi suficient de flexibil sau de agil, dacă te gândești la asta, la faptul că rămânem cu aceeași decizie pe care o luăm acum doi ani. În special o instituție precum DAZN, pe care o trecem de la practic la zero la 3000 de angajați în trei ani. Deci, după cum vă puteți imagina, a fost o creștere masivă și a fost o creștere masivă atât pentru companie, cât și pentru baza de utilizatori.

Drew: Există o modalitate stabilită prin care diferitele Micro-frontend să partajeze date și să comunice între ele, de exemplu, doar pentru a se menține în pas cu aceeași viziune sau există o modalitate de a face asta?

Luca: Da, există. Depinde care dintre cadrul decizional, calea pe care o vei urma. Pentru că dacă ai de gând să iei felia verticală, a devenit foarte ușor. Deci, ceea ce avem pentru a comunica prin Micro-frontend este un shell de aplicație care se încarcă în Micro-frontend în interiorul său. Și ceea ce face este să stocheze tot ceea ce trebuie să fie, să spunem, partajat prin diferite Micro-frontend sau pe un spațiu de stocare web, fie o sesiune, fie o stocare locală, fie în memorie. Și apoi, pe baza acestor informații, Micro-frontend-ul este încărcat, poate prelua din shell-ul aplicației aceste informații și apoi le consumă, le modifică sau le schimbă. Depinde complet de modul în care tăiați aplicația, dar în acest caz, doar pentru a oferi un exemplu, dacă vă gândiți că atunci când sunteți utilizatori autentificați și trebuie să mergeți la pagina de conectare, atunci când vă conectați și API-urile sunt consumate de noi și ei furnizează un token JWT, Micro-frontend le transmite shell-ului aplicației, iar shell-ul aplicației, începând cu acestea, le-am salvat stocarea web.

Luca: Apoi, după aceea, shell-ul aplicației încarcă noua zonă autentificată pentru acea aplicație specifică și acele zone autentificate, preiau jetonul JWT din shell-ul aplicației și efectuează fie un jeton de acces de reîmprospătare, fie validează unele date începând din interiorul Jeton JWT. Deci, se utilizează practic informațiile care au fost produse de un alt Micro-frontend la volanul lor.

Drew: Pare un concept foarte interesant și pot vedea o mulțime de avantaje mari în lucrul în acest fel, dar nu poate fi fără provocările sale, cu siguranță. Există anumite lucruri care sunt mai dificil de tratat atunci când arhitecți lucrurile în acest fel?

Luca: Cred că, în primul rând, principalele provocări pe care le văd sunt schimbarea mentalității. Pentru că înainte eram obișnuiți să avem, să spunem, liderii tehnologici sau dezvoltatorii principali care decideau totul în jurul unei întregi aplicații, luând toate deciziile. Acum, în sfârșit, trecem de la această entitate centralizată la o entitate descentralizată care este locală pentru fiecare stat. După cum vă puteți imagina, acest lucru aduce unele provocări, deoarece dacă înainte avem pe cineva care urmărește calea, acum avem, să spunem, mai mulți oameni în frunte care definesc calea corectă în domeniul lor, iar aceasta este o schimbare uriașă. de mentalitate.

Luca: Pe de altă parte, cred că complexitatea constă în acceptarea uneori că o abstracție greșită ar putea fi, să spunem, mai scumpă decât duplicarea codului. Și asta înseamnă că știu că există ceva care mi s-a părut foarte provocator în gestionarea dezvoltatorilor, deoarece aceștia se gândesc: „Bine, acum pot reutiliza acest obiect sau această bibliotecă specifică de sute de ori în cadrul proiectului”, dar realitatea este foarte diferită. Am văzut biblioteci de componente care erau abstracte și petrec mult timp făcându-l cel mai bun cod vreodată sau cel mai bun într-o formă perfectă. Dar realitatea a fost folosită doar de două ori. Deci efortul de a face asta, nu a fost chiar asta. Am văzut pe cealaltă parte bibliotecile că au început cu câteva cazuri de utilizare pentru o anumită componentă. Și atunci acele cazuri de utilizare au devenit 10 și apoi codul a devenit de neîntreținut.

Luca: Deci, încercarea de a adăuga o nouă funcție în interiorul aceleiași componente ar putea fi mai mult riscantă decât un beneficiu. Așa că cred că celălalt lucru pe care trebuie să-l înțelegem cu Micro-frontend este cât de mult vrem să-l partajăm și cât de mult vrem să duplicăm. Și nu există niciun rău, sincer, duplicarea. În cazul nostru, de exemplu, avem o duplicare a subsolului și antetului și am făcut asta în principal pentru că am schimbat de trei ori antetul în patru ani. Deci, după cum vă puteți imagina, faptul că le centralizăm, suntem alocați unei echipe și creăm o dependență externă pentru toate echipele, toate sutele de dezvoltatori pe care le avem, este mai mult să spunem o problemă decât un beneficiu pentru companie, deoarece nu adăugăm o valoare enormă.

Luca: În același timp, în prezent facem refactorizare, bibliotecile noastre partajate care ar fi bibliotecă de plată, pentru că, evident, plata are o logică în spatele asta și dacă vrem să schimbăm o dată, nu vrem să aplicăm asta de două ori în mai multe părți ale cod. Vrem să avem o singură bibliotecă care să fie o sursă de adevăr, dar pentru antet și subsol, de asemenea, dacă există o discrepanță sau pentru pixel sau există o funcție care este implementată ca o săptămână mai târziu, nu va răni aplicarea.

Drew: Există deci câteva semne revelatoare pe care oamenii ar trebui să le caute atunci când evaluează o aplicație și se gândesc: „Oh, da, acesta ar fi un candidat bun pentru a trece la o arhitectură Micro-frontend?”

Luca: Da, deci sugestia mea ar fi în primul rând că nu aș începe un proiect greenfield cu Micro-frontend decât dacă știm exact cum ar trebui să fie construit. Și, de obicei, este foarte puțin probabil să aveți aceste informații, deoarece, în special dacă aveți o nouă platformă sau un proiect nou și este prima dată când lucrați la asta, ar putea fi o simplă găsire a acestor informații. De obicei, ceea ce sugerez este să începem cu o arhitectură existentă care ar fi o aplicație de o singură pagină și apoi să evoluezi. În special, de exemplu, am descoperit că, folosind Micro-frontend pentru aplicații vechi sau când dorim să înlocuim o anumită parte a aplicației sau când avem un proiect pe care dorim să evoluăm și să-l extindem pentru mai multe echipe, acestea sunt trei cazuri de utilizare. că mă simt foarte puternic ar putea să se potrivească arhitecturii Micro-frontend. Evident, asta nu înseamnă că de acum înainte totul ar trebui făcut Micro-frontend, pentru că Micro-frontend nu este deloc glonțul de argint.

Luca: Ceea ce sunt acestea este o arhitectură suplimentară pe care o putem folosi în lumea front-end. Și până acum aveam o anumită cantitate de arhitecturi, acum avem una în plus. Dar acestea sunt o mulțime de provocări, deoarece evident că trebuie, dacă înainte de randarea pe server sau a unei aplicații pe o singură pagină, există modele clare care au fost explorate și apoi implementate de mai multe cadre și așa mai departe. Cu Micro-frontend în prezent, este o modalitate de a face lucrurile. Dar adăugarea cadrului de decizie ar trebui probabil să permită oamenilor să ia deciziile corecte pentru cazurile lor de utilizare. Pentru că deseori există o mulțime de concepții greșite cu privire la ce sunt micro-frontend și cum ar trebui utilizate. Și mulți oameni se gândesc că poate, să spunem, sunt răi pentru, nu știu, având prea multe biblioteci într-o vedere sau în alte lucruri.

Luca: Realitatea este că trebuie să înțelegi profund conceptul, să înțelegi cum să-l implementezi și apoi poți începe să lucrezi la asta. Sunt pe deplin de acord că există provocări tehnice și sunt multe decizii pe care trebuie să le iei și nu poți începe imediat cu un editor în fața ta să scrie cod și să te gândești, bine, acum creez un micro-frontend arhitectură. Pentru că trebuie să înțelegeți conceptul, să înțelegeți contextul și să creați, de asemenea, guvernare în jurul acestuia, deoarece complexitatea nu este doar scrierea codului, ci și înțelegerea modului în care toate piesele se potrivesc împreună în partea CICD, partea SEO și așa mai departe.

Luca: Așadar, micro-frontend oferă, să spunem, un nivel de flexibilitate și necesită mult efort pentru definirea dreptului de guvernare. Pentru că atunci când ai dreptul de guvernare, totul ar fi bine. Adesea și, din păcate, aș spune prea des, am văzut companii unde nu petrec suficient timp pe partea guvernanței, înțelegând CICD de exemplu, pentru că nu cred că acest lucru este important. Dar, în schimb, pentru Micro-frontend, ca și pentru microservicii, a avea dreptul de automatizare vă va permite să accelerați dezvoltarea. Dacă nu petreceți suficient timp pe bitul de automatizare, riscați să aveți mai multă povară decât beneficii.

Drew: Bănuiesc că sunt atât de multe lucruri în lumea dezvoltării web, în ​​care oamenii sunt în pericol de a se scufunda cu o soluție tehnică înainte să înțeleagă cu adevărat problema. Și se pare că Micro-frontend este un caz în care trebuie să vedeți problema și apoi să implementați soluția pentru a ști ce problemă o rezolvați. Cred că însăși natura Micro-frontend-ului face foarte ușor să începeți integrarea într-o aplicație existentă, să descoperiți o mică problemă și să o schimbați cu un Micro-frontend pentru a rezolva problema. Este o sugestie rezonabilă?

Luca: Da, așa aș spune. În acest caz, singurul lucru pe care l-aș sugera dacă începem în acest fel este să ne uităm mai mult la felierea verticală peste cea orizontală, pentru că altfel trebuie să rezolvați atâtea probleme, să presupunem că, de exemplu, utilizați Angular. și doriți să treceți la o nouă versiune de Angular. Dacă aveți nevoie să aveți două versiuni Angular care locuiesc împreună fără a utiliza I-frame, ar putea fi complicat sau chiar imposibil. Deci, dacă începi, aspectul nu de la... dacă verifici provocarea, nu din punct de vedere tehnic, ci din punct de vedere al afacerii. Poate, de exemplu, puteți lua, nu știu, partea de conectare pe care doriți să scrieți cu o versiune diferită sau aceeași versiune, dar cu o versiune mai actualizată a unui cadru și aceasta ar putea fi o modalitate bună. Și apoi faci drum prin potecă. Aceasta ar putea fi o modalitate bună de a înlocui încet, dar constant, o anumită aplicație.

Luca: Ceea ce am făcut în cazul nostru a fost practic aplicarea modelului strangler care este un model bine cunoscut pentru microservicii, dar pe front end. Deci, pe baza URL-ului și pe baza browserului și a țării utilizatorului. Atât de încet, dar constant, practic am ucis monolitul, care în acest caz a fost o aplicație cu o singură pagină, lansând noua noastră aplicație mai des și să vedem comportamentele utilizatorilor, dacă a îmbunătățit experiența, a cauzat orice problemă în sistemul nostru sau nu. Și asta ne-a permis să oferim valoare imediată afacerii, dar în același timp ne-a permis să ne testăm ipotezele și să vedem dacă mergem în direcția corectă sau nu.

Drew: Pare o soluție foarte atractivă la unele probleme cu care sunt sigur că mulți oameni se confruntă. Dacă eu, ca dezvoltator, aș vrea să încep să investighez mai multe despre Micro-frontend, de unde ar fi un loc bun pentru a începe?

Luca: Da, așa că în prezent îmi petrec mult din timpul liber încercând să susțin aceste arhitecturi, pentru că cred că există o mulțime de concepții greșite. Pe contul meu Medium. Am scris mai multe articole care sunt disponibile și acolo. A înregistrat o mulțime de videoclipuri în conferințe pe care le puteți găsi pe YouTube fără nicio problemă. Și celălalt lucru pe care l-aș sugera dacă sunteți în căutarea unui exemplu de cod pe unele cadre, cel cu care aș recomanda să începeți este un singur SPA, în principal pentru că are o abordare de tăiere verticală, este mai ușor să-l ridicați și puteți începe să înțelegeți beneficiile acestei arhitecturi. Apoi sunt multe altele care sunt disponibile. Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.