Smashing Podcast Episodio 6 Con Luca Mezzalira: cosa sono i micro-frontend?

Concludiamo quest'anno con l'ennesimo podcast Smashing! Questa volta parleremo di micro-frontend. Che cos'è un micro-frontend? In che modo è diverso dal tipo di approccio che potremmo adottare in questo momento? Scopriamolo dal pioniere del micro-frontend, Luca Mezzalira.

Mostra note

Aggiornamento settimanale

• "Aggiunta di funzionalità dinamiche e asincrone ai siti JAMstack", Jason Lengstorf
• "Strumenti di dati quantitativi per i progettisti di UX", Adonis Raduca
• "Creazione di abilità vocali per Google Assistant e Amazon Alexa", Tris Tolliday
• "Oltre Sprint 0: un'alternativa per l'integrazione dei team", Shamsi Brinn
• "Aiutare i browser a ottimizzare con la proprietà Conte CSS", Rachel Andrew

Micro-frontend

• Il sito di Luca Mezzalira
• Luca su Twitter
• “Micro-Frontend, il futuro delle architetture di frontend” su Medium
• Altri scritti di Luca sui micro-frontend possono essere trovati sul suo account Medium
• Il libro di Luca “Architetture reattive front-end”

Trascrizione

Drew McLellan: È uno sviluppatore Google esperto di tecnologie web e manager della comunità JavaScript di Londra. Con oltre 15 anni di esperienza, attualmente lavora come VP of Architecture, progettando la piattaforma di video sportivi DAZN, che offre contenuti sportivi on demand a milioni di utenti che guardano tutti dal vivo. È l'autore del libro Front-End Reactive Architectures per Apress ed è anche revisore tecnico per Apress, Packt Publishing, Pragmatic Bookshelf e O'Reilly, oltre ad essere un relatore pubblico esperto in conferenze tecniche in tutto il mondo. È italiano, sfoggia una bella barba e chiaramente ha una profonda conoscenza della piattaforma web. Ma lo sapevi che una volta ha attraversato il Sud America su uno struzzo? Miei formidabili amici, vi prego di dare il benvenuto a Luca Mezzalira. Ciao, Luca. Come stai?

Luca Mezzalira: Sto spaccando.

Drew: Voglio parlarti oggi dell'argomento dei micro-frontend. Ora questo è un concetto che è completamente nuovo per me, sicuramente dal nome, e mi aspetto che sia nuovo anche per molti dei nostri ascoltatori. Prima di entrare nei micro-frontend stessi, immagino che dovremmo capire il problema che stai cercando di affrontare con loro. Quindi forse potresti parlarci un po' di come vedi le applicazioni in un modo più tradizionale e che tipo di problemi colpiscono quelle cose a cui forse i micro-frontend potrebbero essere la soluzione?

Luca: Va bene, questo è un buon punto di partenza, secondo me. Quindi, di solito, quando si implementa o si progetta un nuovo progetto green field e si desidera lavorare con applicazioni front-end, è possibile sfruttare alcune architetture. È possibile utilizzare un'applicazione a pagina singola, è possibile utilizzare un'applicazione di rendering lato server, oppure è possibile utilizzare un'applicazione multipagina composta da semplici pagine HTML. Ovviamente quelle sono opzioni super valide e penso che siano molto utilizzate da molti, molti sviluppatori. Il vero problema che stiamo cercando di risolvere qui è come puoi ridimensionare questi concetti con team distribuiti a centinaia di sviluppatori che lavorano sulla stessa base di codice, perché la realtà è quando lavori su queste piattaforme in particolare, quando pensi a Piattaforma SaaS, ad esempio, è necessario disporre di più sviluppatori e più team che lavorano allo stesso progetto. E ovviamente il modo in cui, ad esempio, esegui l'acquisizione o la fidelizzazione è completamente diverso nel modo in cui esponi il catalogo o come mostri una parte specifica di una piattaforma.

Luca: Quindi ora nella mia esperienza lavoro molto con l'applicazione a pagina singola. Lavoro con applicazioni di rendering lato server, ma a un certo punto in DAZN mi verrà chiesto di pensare a un modo per ridimensionare il nostro team tecnico. E ho bisogno di venire fuori... se per il back-end abbiamo qualche soluzione che sono i microservizi in questo caso, così possiamo ridimensionare le nostre API in modo indipendente e prendere in considerazione la scala e il volume per un throughput specifico su un'API specifica. Sul front-end, davvero, è davvero più difficile perché se ci pensi, non hai problemi tecnici da risolvere quando devi ridimensionare, se stai utilizzando un'applicazione a pagina singola, ad esempio. Probabilmente per un rendering lato server ne hai alcuni, ma su un'applicazione a pagina singola, ad esempio, è distribuito per natura perché è lato client, lato client diverso.

Luca: Quindi l'unica cosa che stanno caricando sono solo alcuni file statici come CSS e HTML e JavaScript che sono serviti da CDN, e in quel caso puoi ridimensionare di conseguenza, non è una grande sfida. Ma la vera sfida è come ridimensionare i team che lavorano sulla stessa piattaforma, perché a volte le sfide che devono affrontare una squadra potrebbero essere completamente diverse dalle sfide che devono affrontare un'altra squadra, e di solito quello che fai è cercare di trovare molti compromessi tra le cose. Perché se ci pensi, proviamo a pensare a un caso d'uso normale. Quindi di solito quando avvii una piattaforma inizi in piccolo. Quindi provi a creare quella rapida applicazione a pagina singola, oltre al tuo monolito, quindi configuri tutto nel tuo CICD solo una volta per il front-end e il back-end, e quindi inizi a ripetere la tua logica. Ma la realtà è che quando hai successo, devi evolvere questa parte, e non è sempre mantenere la stessa architettura che potrebbe, diciamo, creare vantaggi per il tuo business, perché forse puoi trovare dei colli di bottiglia.

Luca: Quindi ora torniamo alla parte dell'applicazione a pagina singola. Quindi, se vogliamo ridimensionare una parte dell'applicazione a pagina singola, la sfida non è tecnica, è con gli umani, se lo desideri. Quindi, come possiamo ridimensionare i team che lavorano sulla stessa applicazione. Quindi quello che ho fatto alcuni anni fa è stato iniziare a guardare a una possibile architettura che mi avrebbe permesso di scalare sia il front-end che il back-end. Quindi lavorare sui principi di back-end in modo da poter trovare i microservizi. Ho iniziato a guardare la diversa soluzione e sono usciti con i micro-frontend che all'inizio non lo chiamavamo nemmeno così perché ovviamente anni fa non c'era, diciamo, quel nome per quella specifica architettura .

Luca: Ma la realtà è prendere un monolite, quindi un'applicazione a pagina singola e tagliarla in un modo che ci permetta di concentrarci su un piccolo problema. Quindi un problema più piccolo dell'intera applicazione e cercando di risolverlo nel miglior modo possibile. Parlando tecnicamente. Ovviamente ciò porta ad avere parti indipendenti della tua applicazione frontend che potrebbero essere implementate in produzione senza influire su tutte le altre. Quindi la sfida fondamentalmente per Micro-frontend è cercare di capire come prendere un'applicazione a pagina singola o un'applicazione con rendering lato server e creare un artefatto di queste, diciamo, il più vicino possibile a un dominio aziendale, e può essere distribuito in modo indipendente .

Drew: Quindi intendo dire che hai menzionato i micro servizi sul back-end. Quindi concettualmente questo è un tipo simile di soluzione al problema. I microservizi servono sul back-end, ma sono trasferiti sul front-end. È un'equivalenza approssimativa o è più coinvolta in quella?

Luca: Sì. No, è un modo per risolvere lo stesso problema che sta cercando di risolvere i microservizi sul back-end ma sul front-end in questo momento. Di solito quando ho iniziato questo viaggio all'inizio, sai, inizi a pensarci e inizi a valutare approcci diversi. E negli ultimi mesi mi è venuto in mente quello che chiamano, il framework decisionale Micro-frontend che fondamentalmente sono quattro passaggi che usano per, diciamo che identificate un approccio per Micro-frontend, perché se fino ad ora, noi di solito scegliamo un framework che ha progettato l'architettura per noi e lo implementiamo sulla loro architettura. Se pensi ad angular o pensi a React o Redux. Hai tutti i pezzi che ti servono ma non prendi decisioni architettoniche. Prenderesti una decisione di progettazione o come implementare su quell'architettura specifica.

Luca: Quindi su Micro-frontend devi fare un passo indietro. Quindi dobbiamo pensare a come vogliamo prima suddividere la nostra applicazione. Quindi di solito ci sono due opzioni per questo. Puoi tagliare orizzontalmente, in modo da avere più micro-frontend nella stessa vista o puoi tagliare verticalmente. Pertanto carichi sempre un Micro-frontend alla volta. E quelle decisioni sono piuttosto chiave perché poi aggiungeranno a cascata alcune altre opzioni che hai basato sulla decisione iniziale da prendere. Quindi il primo, come ho detto, decidi tu come vuoi suddividere la tua applicazione. Il secondo è come vuoi comporre la tua applicazione. Quindi vuoi avere come, ad esempio, una shell dell'app che sta caricando uno o più micro-frontend nella stessa vista. Vuoi avere, non lo so, un server delle applicazioni che stia componendo diversi frammenti delle tue applicazioni, quindi un Micro-frontend così diverso e quindi offra la vista finale al tuo utente. Oppure vuoi utilizzare edge-side incluso, è uno standard che si trova all'interno dei CDN per comporre una pagina e servirli lì.

Luca: Quelle sono tre delle opzioni che hai. E poi, oltre a comporre, devi pensare a come vuoi instradare. Quindi come instradare, non lo so, /login o /signin alla parte del catalogo o a un oggetto di dettaglio specifico. Anche qui hai tre opzioni. Puoi farlo sul server delle applicazioni, puoi farlo a livello CDN con Lambda Edge o qualsiasi altro web worker in CloudFlare o qualsiasi altra cosa. Oppure puoi creare un sito client. Quindi hai una logica all'interno della shell dell'app che dici, ok, ora per questo URL specifico devi caricare un'altra vista o un altro micro-frontend. E l'ultimo bit è come comunichi con Micro-frontend.

Luca: Quindi di solito se hai più Micro-frontend sulla stessa pagina, c'è una maggiore complessità nella gestione di questa comunicazione, perché è necessario mantenere i diversi Micro-frontend indipendenti. Ciò significa che non puoi avere alcun riferimento su come è strutturata la pagina. Quindi di solito puoi usare cose come eventi personalizzati o un misuratore di eventi che viene iniettato all'interno di ogni singolo Micro-frontend. E poi i Micro-frontend stanno comunicando insieme. Ovviamente nell'altro caso quando hai come diciamo una divisione verticale dal tuo Micro-frontend è molto più semplice, perché all'interno della verticale sostanzialmente la rappresentazione di un Micro-frontend verticale è un'applicazione a pagina singola o una singola pagina. E in tal caso è più facile dire creare e condividere con uno stato condiviso nell'intero Micro-frontend.

Luca: Quindi se pensi di avere più Micro-frontend tutti insieme, allora dovresti evitare di avere stati condivisi attraverso Micro-frontend, perché altrimenti stai accoppiando le cose. Invece dell'intero concetto qui è il disaccoppiamento e lo spiegamento indipendente. E quindi diciamo che le sfide di una divisione orizzontale, che è la prima decisione da prendere o di una divisione verticale, sono completamente diverse e dobbiamo essere molto ben consapevoli di quale si adatta al nostro caso d'uso.

Drew: Quindi, piuttosto che una soluzione tecnica specifica, i micro frontend sono molto simili a un modello di progettazione che implementeresti in qualsiasi tecnologia sia appropriata per il particolare problema che stai cercando di risolvere?

Luca: Sì, più della tecnologia, vedrei che scegliamo l'architettura giusta per il lavoro giusto. Tanto per farti un esempio, stavo parlando... c'è un framework famoso, abbastanza nuovo per Micro-frontend, si chiama Luigi framework, che è stato rilasciato da SAP open source. Quello che stanno facendo è creare alcuni iframe in cui stanno avvolgendo il loro Micro-frontend al suo interno. Quindi ora se ci pensi, diciamo, usando gli iframe al giorno d'oggi, sei su un sito Web pubblico che forse come SEO o altre funzionalità obbligatorie, potrebbe essere problematico.

Luca: Ma nel caso di SAP, se ci pensi, hanno come un'applicazione aziendale in cui possono controllare il browser che l'utente sta utilizzando, possono controllare l'ambiente, non hanno bisogno di essere disponibili su una moltitudine o versione diversa del browser. Quindi per loro queste cose consentono loro di avere determinate aree dell'applicazione che sono costanti e hanno determinate aree che cambiano indipendentemente senza alcun problema. Ma ovviamente una soluzione iframe non funzionerebbe in altre situazioni. Solo per fare un altro esempio, Spotify, all'inizio stiamo usando gli iframe. In effetti la pubblicazione desk è ancora composta da più iframe e ogni singolo iframe è una minuscola applicazione che fa, non so, solo un lettore musicale o solo la loro raccomandazione, qualunque essa sia. Cercano di avere lo stesso approccio sul web, ma quest'anno l'hanno respinto per tornare a un'applicazione a pagina singola.

Luca: E questo significa che spiegano perché nel blog tecnico dicevano che ovviamente se lo si applica a milioni di utenti che utilizzano iframe è necessario caricare ogni volta lo stesso file dei fornitori. E poi hai come molte dipendenze duplicate e il tempo per interagire con la tua pagina sarebbe più lungo. Quindi, in realtà, questo approccio potrebbe adattarsi a determinati casi d'uso, ma non dovrebbero adattarsi a tutti. Ecco perché sto dicendo, come ho descritto prima, se hai un framework decisionale che ti aiuta ad affrontare queste cose e puoi iniziare a dire, ok, ho tagliato l'applicazione in questo modo, quindi ho quelle opzioni che sono disponibili quando voglio comporre, quando voglio indirizzare, quando voglio comunicare, dovrebbe guidarti per prendere la decisione giusta al momento giusto.

Luca: Poi ovviamente a parte queste quattro decisioni, ce ne sono molte altre. Come il modo in cui crei coerenza nel sistema di progettazione che hai in tutto il Micro-frontend. Oppure non so come gestisci le dipendenze ed eviti lo scontro delle dipendenze all'interno del Micro-frontend, ma la realtà è che quelle quattro decisioni di cui ho parlato prima ti permetteranno di prendere poi tutte le altre in maniera veloce senza dover il problema del pensare troppo, che è la soluzione migliore perché hai già posto la pietra angolare, i quattro pilastri, che ti permetteranno di prendere tutte le altre decisioni… non dico in modo semplice, ma in modo più rapido di una recensione o lo spettro delle opportunità.

Drew: Hai menzionato prima il modo in cui Micro-frontend può aiutare con il tipo di struttura dei team all'interno della tua organizzazione e con molte persone che lavorano sulla stessa applicazione. Quali sono quindi alcune delle implicazioni e fa la differenza se i tuoi team sono distribuiti o co-localizzati o ci sono delle sfide che devono essere affrontate lì?

Luca: Sì. Quindi posso raccontarvi qual è la storia di DAZN. Questa è l'azienda su cui sto lavorando. Attualmente in DAZN abbiamo affrontato una bella sfida. Quindi attualmente abbiamo oltre 300 persone che lavorano sul front e sul back-end della nostra piattaforma. È una piattaforma OTT che trasmette in streaming live in occasione di eventi sportivi a livello globale. E la cosa interessante è se tutti i microservizi sappiamo come gestirli più o meno e abbiamo dei team distribuiti. Quindi abbiamo quattro centri di sviluppo. Vorremmo mettere le squadre in ogni singolo centro di sviluppo in prima linea, e abbiamo provato questo approccio e ha funzionato abbastanza bene. Quindi, con Micro-frontend siamo stati in grado di fornire domini aziendali diversi in luoghi diversi e consentire la comunicazione incrociata tra i team all'interno di un dominio aziendale specifico, proprio perché lo scenario peggiore è che se devi parlare con un altro team nel tuo stesso dominio aziendale , raggiungi solo la distanza a piedi dalla tua scrivania. Se invece hai bisogno di discutere di cose specifiche nel team di distribuzione, quindi magari con qualcuno a Londra invece che ad Amsterdam, o invece di un'azienda in Polonia, organizzi semplicemente una chiamata.

Luca: Ma questi tipi di comunicazione sono più rari di quelli che avvengono tra i team all'interno della stessa posizione. Ed è per questo che abbiamo iniziato a lavorarci. Quindi la prima cosa che hanno fatto è stata guardare come i nostri utenti interagivano con il nostro sito Web, come era strutturata l'azienda. E quando identifichiamo le quattro aree chiave su cui stiamo lavorando, che sono attualmente l'acquisizione e la conservazione, diciamo il porting della loro applicazione principale su più TV e dispositivi mobili e il dominio principale che per noi è il lettore video e la fase di scoperta di il nostro contenuto. E infine tutti gli elementi del back office. Sono stato in grado di identificare quelle quattro aree e noi quelle quattro aree che abbiamo assegnato per ogni singolo centro di sviluppo.

Luca: Ovviamente ci sono alcuni punti di contatto tra queste aree, ma poi ci sono modi in cui puoi dire mitigare e fare un seminario iniziale con i diversi team che si trovano in luoghi diversi e poi lavorare per lo stesso contratto API, ad esempio, o lo stesso obiettivo con alcuni checkpoint durante lo sviluppo. Ma la cosa bella dell'approccio che ha permesso l'approccio con Micro-frontend è il fatto che finalmente capiamo a fondo come funzionava il nostro sistema. Ci sediamo e analizziamo come eravamo strutturati e abbiamo cambiato non solo il modo in cui siamo stati influenzati, ma anche il modo in cui l'azienda stava lavorando. E quello era un approccio diverso da quello che hanno visto finora. Ma sta dimostrando che funziona abbastanza bene nel caso in cui ogni singolo team possa interagire con il team della stessa posizione nello stesso dominio.

Luca: Quindi stanno parlando esattamente nella stessa lingua se si parla del design basato sul dominio. E questo è che se hanno bisogno di interagire con altri team, possono letteralmente condividere il workshop o volare in un altro centro di sviluppo ed è meno che un problema. Ma in questo modo, diciamo, aumentiamo il throughput e riduciamo il sovraccarico di comunicazione e l'entità delle dipendenze che si verificavano in altre situazioni su cui stavano lavorando.

Drew: E tutti questi team devono utilizzare come un framework JavaScript standardizzato? Devono essere tutti codificati nelle stesse cose, devono essere tutti React o Angular o consentire l'interoperabilità tra loro o le persone possono usare cose diverse per diversi Micro-frontend?

Luca: Sì. Quindi in DAZN abbiamo deciso di tagliare verticalmente il nostro Micro-frontend e questa è stata una decisione che ci ha permesso di avere la libertà di scegliere la tecnologia di cui avevamo bisogno per ogni singolo Micro-frontend. Considerando che ogni volta carichiamo un Micro-frontend alla volta e questo significa che, ad esempio, il modo in cui abbiamo una pagina di destinazione è diverso dal percorso di accesso/registrazione. Quindi possiamo aggiornare... stiamo usando principalmente React al momento. Ma se, per esempio, ricordo quando React 16 era una release che siamo riusciti a rilasciare in produzione React 16, anche se non era nella versione stabile solo per una landing page e vedo se funzionava senza intaccare tutti i altre squadre.

Luca: E poi alla loro velocità, al loro ritmo, stavano aggiornando le proprie cose. Quindi questo ci permette anche di provare, diciamo, nuove tecnologie o nuove ipotesi che abbiamo sull'applicazione esistente con un certo numero di utenti. Perché implementiamo anche le versioni candidate per il front-end. Implementiamo le, diciamo, diverse pratiche che ci consentono di provare determinati tempi in produzione e vedere come funzionano le cose.

Luca: La bellezza di questi approcci è che possiamo decidere autonomamente di avere lo strumento giusto per il lavoro giusto più che avere un denominatore comune sull'intero stack. Perché come puoi immaginare, quando hai iniziato a lavorare su un progetto, le decisioni che hai preso i primi anni probabilmente sono diverse rispetto a quelle che hai preso in una traiettoria in cui l'azienda cresce, il business si evolve e questi sono diventati più maturi e la sfida è completamente diversa. Quindi non sarebbe abbastanza flessibile o agile, se ci pensi, il fatto che manteniamo la stessa decisione che abbiamo preso due anni fa. In particolare un ente come DAZN, che in tre anni passiamo da zero a 3000 dipendenti. Quindi, come puoi immaginare, è stata una crescita massiccia ed è stata una crescita massiccia per l'azienda e per la base di utenti.

Drew: C'è un modo stabilito per i diversi Micro-frontend di condividere dati e comunicare tra loro, ad esempio, solo per tenersi al passo con la stessa vista o c'è un modo per farlo?

Luca: Sì, c'è. Dipende da quale quadro decisionale, quale percorso hai intenzione di intraprendere. Perché se hai intenzione di prendere la fetta verticale è diventato molto facile. Quindi quello che abbiamo per comunicare tramite Micro-frontend è una shell dell'app che si sta caricando in Micro-frontend al suo interno. E quello che fa è archiviare tutto ciò che deve essere, diciamo, condiviso su diversi Micro-frontend o su un archivio Web, una sessione o un archivio locale o in memoria. E quindi in base a tali informazioni, il Micro-frontend viene caricato, può recuperare dalla shell dell'app queste informazioni e quindi consumarle, modificarle o cambiarle. Dipende completamente da come affettare l'applicazione, ma in questo caso, solo per fornire un esempio, se pensi che quando sei un utente autenticato e devi andare alla pagina di accesso, quando accedi e le API sono le nostre consumate e stanno fornendo un token JWT, Micro-frontend li sta passando alla shell dell'app e la shell dell'app ha iniziato a salvare il loro spazio di archiviazione web.

Luca: Quindi, dopo che la shell dell'app sta caricando la nuova area autenticata per quella specifica applicazione e quelle aree autenticate, stanno recuperando il token JWT dalla shell dell'app e stanno eseguendo un aggiornamento del token di accesso o stanno convalidando alcuni dati che iniziano all'interno di token JWT. Quindi utilizza fondamentalmente le informazioni che sono state prodotte da un altro Micro-frontend al proprio volante.

Drew: Sembra un concetto molto interessante e posso potenzialmente vedere molti grandi vantaggi nel lavorare in questo modo, ma sicuramente non può essere privo di sfide. Ci sono cose particolari che sono più difficili da affrontare quando si architettano le cose in questo modo?

Luca: Penso che prima di tutto la principale sfida che vedo sia il cambiamento di mentalità. Perché prima eravamo abituati ad avere, diciamo, i leader tecnologici o gli sviluppatori principali che decidevano tutto attorno a un'intera applicazione prendendo tutte le decisioni. Ora finalmente passiamo da questa entità centralizzata a un'entità decentralizzata che è locale per ogni stato. Come puoi immaginare, questo sta portando alcune sfide perché se prima abbiamo qualcuno che sta tracciando il percorso, ora abbiamo, diciamo, più persone in alto che definiscono il percorso giusto all'interno del loro dominio, e questo è un enorme cambiamento di mentalità.

Luca: D'altra parte, penso che la complessità sia accettare che a volte l'astrazione sbagliata possa essere, diciamo, più costosa della duplicazione del codice. So che c'è qualcosa che ho trovato molto impegnativo nella gestione degli sviluppatori perché stanno pensando: "Ok, ora posso riutilizzare questo oggetto o questa libreria specifica centinaia di volte all'interno del progetto", ma la realtà è molto diversa. Ho visto una libreria di componenti che era astratta e trascorrono molto tempo a realizzarla come il miglior codice in assoluto o il migliore in una forma perfetta. Ma la realtà è stata usata solo due volte. Quindi lo sforzo di farlo, non era esattamente quello. Ho visto dall'altra parte le librerie che hanno iniziato con un paio di casi d'uso per un componente specifico. E poi quei casi d'uso sono diventati 10 e quindi il codice è diventato ingestibile.

Luca: Quindi provare ad aggiungere una nuova funzione all'interno dello stesso componente potrebbe essere più rischioso che vantaggioso. Quindi penso che l'altra cosa che dobbiamo capire con Micro-frontend è quanto vogliamo condividerlo e quanto vogliamo duplicare. E non c'è niente di male, onestamente, duplicare. Nel nostro caso, ad esempio, abbiamo una duplicazione di piè di pagina e intestazione, e l'abbiamo fatto principalmente perché abbiamo cambiato tre volte l'intestazione in quattro anni. Quindi, come puoi immaginare, il fatto che li stiamo centralizzando, sono assegnati a un team e creiamo una dipendenza esterna per tutti i team, tutte le centinaia di sviluppatori che abbiamo, è più diciamo un problema che un vantaggio per l'azienda perché non stiamo aggiungendo un valore enorme.

Luca: Allo stesso tempo attualmente stiamo refactoring, le nostre librerie condivise che sarebbero librerie di pagamento, perché ovviamente il pagamento ha una logica dietro e se vogliamo cambiarlo una volta, non vogliamo applicarlo due volte in più parti del codice. Vogliamo avere solo una libreria che sia una fonte di verità, ma per l'intestazione e il piè di pagina, anche se c'è una discrepanza o per pixel o c'è una funzione che viene implementata come una settimana dopo, non danneggerà il applicazione.

Drew: Quindi ci sono alcuni segnali rivelatori che le persone dovrebbero cercare quando valutano un'applicazione e pensano: "Oh sì, questo sarebbe un buon candidato per passare a un tipo di architettura Micro-frontend?"

Luca: Sì, quindi il mio suggerimento sarebbe innanzitutto di non avviare un progetto greenfield con Micro-frontend a meno che non sappiamo esattamente come dovrebbe essere costruito. E di solito è molto improbabile che tu abbia queste informazioni perché, in particolare se hai una nuova piattaforma o un nuovo progetto ed è la prima volta che ci lavori, potrebbe essere non banale trovare queste informazioni. Di solito quello che suggerisco è iniziare con un'architettura esistente che sarebbe così un'applicazione a pagina singola e poi evolverla. In particolare, ad esempio, ho scoperto che penso che usare Micro-frontend per applicazioni legacy o quando vogliamo sostituire una parte specifica dell'applicazione o quando abbiamo un progetto che vogliamo evolvere e ridimensionare per più team, questi sono tre casi d'uso che ritengo molto forte potrebbe adattarsi all'architettura Micro-frontend. Ovviamente ciò non significa che d'ora in poi tutto dovrebbe essere fatto Micro-frontend, perché il Micro-frontend non è affatto il proiettile d'argento.

Luca: Quello che sono è un'architettura aggiuntiva che possiamo sfruttare nel mondo del front end. E fino ad ora avevamo una certa quantità di architetture, ora ne abbiamo una in più. Ma sono molte sfide perché ovviamente è necessario, se prima del rendering lato server o di un'applicazione a pagina singola, ci sono modelli chiari che sono stati esplorati e quindi implementati da diversi framework e così via. Con Micro-frontend attualmente, è un modo per fare le cose. Ma l'aggiunta del framework decisionale probabilmente dovrebbe consentire alle persone di prendere le decisioni giuste per i loro casi d'uso. Perché spesso ci sono molte idee sbagliate su cosa siano i Micro-frontend e su come dovrebbero essere usati. E molte persone stanno pensando che forse, diciamo, sono malvagie perché, non so, avere troppe librerie in una vista o altre cose.

Luca: La realtà è che devi capire a fondo il concetto, capire come implementarlo e poi puoi iniziare a lavorarci. Sono pienamente d'accordo sul fatto che ci sono sfide tecniche e ci sono molte decisioni che devi prendere e non puoi iniziare subito con un editor di fronte a te che scrive codice e pensa, ok, ora sto creando un micro-frontend architettura. Perché è necessario comprendere il concetto, comprendere il contesto e creare, anche la governance intorno a questo perché la complessità non è solo scrivere il codice, è anche capire come tutti i pezzi si incastrano nella parte CICD, la parte SEO e così via.

Luca: Quindi il micro-frontend fornisce, diciamo, un livello di flessibilità e richiede molto sforzo per definire la governance giusta. Perché quando hai la governance giusta, tutto andrebbe liscio. Spesso e purtroppo direi troppo spesso, ho visto aziende in cui non dedicano abbastanza tempo al lato governance, capire ad esempio il CICD, perché non pensano che questo sia importante. Ma invece per Micro-frontend, come per i microservizi, avere l'automazione giusta ti consentirà di accelerare lo sviluppo. Se non dedichi abbastanza tempo al bit di automazione, rischi di avere più oneri che vantaggi.

Drew: Immagino che siano come tante cose nel mondo dello sviluppo web in cui le persone corrono il rischio di immergersi in una soluzione tecnica prima di aver veramente compreso il problema. E sembra che con Micro-frontend sia davvero un caso in cui devi vedere il problema e quindi implementare la soluzione per sapere quale problema stai risolvendo. Immagino che la natura stessa del Micro-frontend renda molto facile iniziare l'integrazione in un'applicazione esistente, individuare un piccolo problema e sostituirlo con un Micro-frontend per risolvere quel problema. È un suggerimento ragionevole?

Luca: Sì, direi di sì. In questo caso, l'unica cosa che suggerirei se iniziamo in questo modo è guardare più lo slicing verticale rispetto all'slicing orizzontale, perché altrimenti devi risolvere tanti problemi in merito, supponiamo che tu ad esempio tu stia usando Angular e vuoi passare a una nuova versione di Angular. Se hai bisogno di avere due versioni Angular che convivono senza usare I-frame, potrebbe essere complicato o addirittura impossibile. Quindi se inizi, l'aspetto non da... se controlli la sfida, non dal punto di vista tecnico, ma dal punto di vista aziendale. Forse, ad esempio, puoi prendere, non lo so, la parte di accesso su cui vuoi scrivere con una versione diversa o la stessa versione ma più versione di aggiornamento di un framework e potrebbe essere un buon modo. E poi percorri il sentiero. Potrebbe essere un buon modo per sostituire lentamente ma costantemente un'applicazione specifica.

Luca: Quello che abbiamo fatto nel nostro caso è sostanzialmente applicare il pattern strangolatore che è un pattern ben noto per i microservizi, ma sul front-end. Quindi in base all'URL e in base al browser e al paese dell'utente. Così lentamente ma costantemente, in pratica stavamo uccidendo il monolito, che in questo caso era un'applicazione a pagina singola, rilasciando la nostra nuova applicazione più spesso e vedere i comportamenti degli utenti, se stava migliorando l'esperienza, stava causando qualche problema al nostro sistema o no. E questo ci ha permesso di fornire un valore immediato al business, ma allo stesso tempo ci ha permesso di testare le nostre ipotesi e vedere se stavamo andando nella giusta direzione o meno.

Drew: Sembra una soluzione molto interessante per alcuni problemi che sono sicuro che molte persone stanno affrontando. Se io, come sviluppatore, volessi iniziare a indagare di più sul Micro-frontend, quale sarebbe un buon punto di partenza?

Luca: Sì, quindi attualmente sto spendendo molto del mio tempo libero cercando di difendere queste architetture, perché penso che ci siano molte idee sbagliate. Sul mio conto Medio. Ho scritto diversi articoli che sono disponibili anche lì. A ha registrato molti video in conferenze che puoi trovare su YouTube senza alcun problema. E l'altra cosa che suggerirei se stai cercando qualche esempio di codice su alcuni framework, quello con cui consiglierei di iniziare è una singola SPA, principalmente perché ha un approccio di slicing verticale, è più facile prenderlo e puoi iniziare a capire i vantaggi di questa architettura. Poi ce ne sono molti altri disponibili. 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.