Benvenuti su GITBAR, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.[Musica] Bene e benvenuti in questo nuovo episodio di Geekbar.Controllando bene dovrebbe essere già l'episodio numero 39.Sembra ieri che siamo partiti.In questo episodio ahimè sono da solo.Sono da sola a provare a raccontarvi, cercando di dare un contesto, un argomento che abbiamo già introdotto in una delle nostre puntate.per essere più precisi la puntata numero 35 quando con noi qua c'era appunto Luca Mezzalira di DAZN.Oggi proviamo in qualche modo a cercare di raccontare questa tecnologia, anzi questo approccio alla tecnologia in modo da avere una visione di insieme un pochino più chiara, più dettagliata e lo faremo naturalmente subito dopo avervi ricordato i nostri contatti come ben sapete potete scrivermi a info@gitbar.it oppure scrivermi su twitter @brainrepo però tenete presente che a questi media darò sempre meno spazio meno spazio perché dalla prossima settimana siamo partiti con il gruppo telegram.Il gruppo telegram ci permette di avere un pelino più di interattività e quindi potete scrivermi e io vi rispondo in tempo reale.Spero che si inneschino una serie di discussioni all'interno del gruppo perché penso sia lo strumento giusto in realtà per condividere.condividere.Mi sembrava che Gitbar stesse prendendo una deriva molto unidirezionale invece voglio proprio costruire le puntate con voi e lo strumento che ho scelto per poterlo fare quello che ci può aiutare meglio in questo percorso è appunto Telegram per cui iscrivetevi.Come si fa ad iscrivervi? Telegram sapete già come si usa probabilmente lo sapete anche meglio di me visto che ancora non sono stato in grado di apprendere i rudimenti per la gestione di gruppi ma vi prometto che lo farò comunque potete trovarlo aprendo il browser e scrivendo t.me/gitbar ripeto t.me/gitbar il nome del nostro podcast e andando a questo indirizzo vi si aprirà direttamente telegram iscrivetevi perché di lì passeranno tutte le informazioni detto questo piccola pausa e poi iniziamo ad aprire il fantastico e anche un po' inflazionato a livello di buzzword mondo del micro frontend "è arrivato la rovina" Provo a raccontarvi micro front-end così come ho fatto nella lezione introduttiva di qualche giorno fa appunto nel corso di micro front-end e lo faccio raccontandovi una storia ipotetica abbiamo lanciato da poco un'applicazione applicazione che non esiste ma mi serve per rendere l'idea che si chiama petflix che è insomma una netflix degli animali domestici.L'abbiamo appena lanciata, è una startup, siamo in pochi siamo in tre a sviluppare questa applicazione per cui il team è abbastanza piccolo.All'interno di questo team piccolo la comunicazione che si va a costruire è molto semplice in realtà.Ogni membro del team riesce con degli scambi molto rapidi a essere a conoscenza di tutte le scelte sia tecniche che a livello di business della nostra startup.Questo fa sì che in realtà all'interno appunto di petflix le funzionalità vengano sviluppate con una certa velocità e le decisioni sia che siano legate all'architettura, che legate ai tool che si utilizzano o al dominio di business stesso quindi i processi di business vengono presi in modo molto rapido molto snello senza milioni di di riunioni ping pong o di riunioni o di messaggi ping pong che partono da una parte all'altra e fondamentalmente le decisioni si possono prendere davanti a una macchinetta del caffè però non sempre così piano piano la nostra startup cresce e come cresce anche il numero degli sviluppatori si ingrandisce quindi ci sono più persone che lavorano alla stessa codebase.Più persone vuole anche dire che ogni sviluppatore inizia ad avere difficoltà a conoscere tutte le funzionalità della nostra applicazione o del prodotto che vogliamo realizzare.Perché? Perché allo stesso tempo anche il prodotto cresce.Per cui tutte queste funzionalità non le possiamo mandare a memoria e tutte le scelte relative a queste funzionalità non possiamo memorizzarle per cui si creano tutta una serie di situazioni per cui le conoscenze relative appunto alla nostra applicazione e alle scelte tecniche alle tecnologie che vengono utilizzate si dividono in silos quindi dei compartimenti stagni dove da una parte all'altra è molto difficile che le informazioni transitino.In questo contesto ci si trova davanti alla condizione per cui per prendere le decisioni bisogna fare decine di riunioni anche per prendere le decisioni più banali.Decine di riunioni che si trasformano in modo molto semplice in tempo perso.Per cui morale della favola quello che abbiamo visto è che allo scalare dei membri dei team nella nostra applicazione con la stessa velocità in realtà non scala anche la parte di produttività quindi in realtà non è che se incremento il mio team del 50% la produttività scala del 50% in realtà si vede che appunto la crescita non è proporzionale.Allora è necessario andare a trovare delle soluzioni per andare in qualche modo a coprire questo tipo di problematica.Quali sono allora le strategie che possiamo mettere in campo per cercare di mettere appunto una pezza a questo tipo di problematiche e per affrontarle? La prima cosa che viene in mente quando ci si trova davanti a questi contesti è provare a utilizzare quella famosa frase che in realtà all'università ci ripetevano tanto, che era appunto la "divide e t'impera".Una soluzione classica che risale, se torniamo indietro, ai tempi degli antichi romani fino a passare per Luigi XI, Filippo il Macedone, fino ad arrivare all'impero coloniale britannico.una soluzione che ha delle radici abbastanza solide e che si propone per risolvere il nostro problema.Infatti dividendo il nostro progetto in più parti dovremmo essere in grado di mitigare gli effetti appunto di un contesto che difficilmente scala.In realtà quando andiamo a a dividere il nostro progetto, quello che ci viene semplice fare è uno slicing chiamato slicing orizzontale.Quindi immaginiamo di prendere un coltello e andare ad affettare la nostra complessità in modo orizzontale.Perché dico orizzontale? Perché in realtà ogni fetta di complessità porta con sé un certo contesto.Per esempio divideremo i backender con i backender, i frontender con i front-ender, gli ops tra di loro e i data engineer tra di loro.Questo perché in realtà è molto semplice.I front-ender parlano la stessa lingua tra di loro per cui ci viene molto semplice metterli insieme così come gli ops, i data engineer e i back-ender hanno un linguaggio comune, utilizzano gli stessi tool per cui questa divisione viene quasi naturale.quello che però ci si presenta poi alla porta è un conto abbastanza salato ed è il conto che porta con sé nuovi silo e nuovi problemi questo perché in realtà la comunicazione tra back-ender e front-ender in realtà o tra contesti e tra slice orizzontali differenti non è poi così snella e non così poi così appunto semplice.Quindi dobbiamo trovare una soluzione.La prima cosa che viene in mente è provare a cambiare la metodologia nella quale si fanno queste fette, questi slice.E se al posto di affettare questa nostra torta in modo orizzontale provassimo a tagliarla in modo verticale e quindi provassimo a prendere un contesto della nostra applicazione che vada la persistenza alla logica d'interfaccia passando per le operation il back end quindi in realtà andiamo ad affettare la nostra torta per feature fondamentalmente quindi per pezzettini degli user journey del viaggio del nostro utente che hanno un contesto coerente al loro interno.In realtà questa divisione si differenzia dalla divisione tipica dei microservizi proprio perché va a prendere tutta l'applicazione end to end dal database al front end.In questo caso noi riusciamo ad ottenere tutta una serie di vantaggi.Per esempio le decisioni vengono prese all'interno dei team.Team che sono indipendenti e quindi sono in grado di per quella feature poter decidere praticamente tutto.Questo vuol dire e questo facilmente si tramutta in meno riunioni di coordinamento tra più team e ritorniamo in una situazione tipo quella iniziale dove le decisioni venivano prese alla macchinetta del caffè in più, avendo un progetto che poi diventa più piccolo perché ogni team dovrà prendere solo una porzione del progetto si acquistano tutta un'altra serie di vantaggi, non per ultimo quello di avere un progetto più piccolo quindi più facile da rifattorializzare volendo più comodo switchare la tecnologia per questo progetto perché perché in realtà sta in un contesto isolato non influisce con il resto delle delle feature è più semplice fare in modo che gli sviluppatori di un team siano a conoscenza di tutti i dettagli tecnici implementativi e di funzionalità di quella feature specifica e quindi alla fine diventa molto più comodo riuscire appunto a modernare la tecnologia.Come ha detto Luca Mezzalira appunto in uno dei nostri episodi, i micro front end quindi che sono diciamo la parola che cerca di riassumere questo tipo di contesto dove i team sono sviluppati end to end per cui abbiamo l'esigenza di dividere la nostra applicazione in diversi front end che dobbiamo integrare.I micro front end non sono solo una tecnologia ma sono più che altro un approccio organizzativo e architetturale.Questa cosa è da tenere in mente perché in realtà l'implementare i micro front end può essere fatto in modo in modi completamente diversi.quello che però noi stiamo andando a fare fondamentalmente è quello di dividere il nostro user journey in use case e questi use case stiamo andando a svilupparli in un modo abbastanza isolato da permettere appunto a questi casi d'uso a queste feature di avere una vita propria quindi abbiamo preso la nostra applicazione e l'abbiamo divisa in casi d'uso.Per questi casi d'uso abbiamo sviluppato delle funzionalità funzionalità che potremmo anche chiamare sistemi ognuno dei quali è completamente autonomo e funziona a prescindere dagli altri.E' autonomo perché possiede dal datastore al front end a tutti i microservizi a corredo.Tutti questi elementi vengono orchestrati per servire quel sistema specifico.E un'altra cosa interessante è che per quel sistema esiste un team dedicato.E' molto importante fare un focus sul team perché diciamo che il motore, quell'elemento che è in condizione sine qua non è, fa sì che la feature venga sviluppata, quindi che il sistema prenda corpo.Se dovessi raccontarvi i team mi viene in mente un'idea di slicing fatta sulle funzionalità del sito di github c'è un team che lavora alle funzioni core git quindi tutto ciò che riguarda la parte più core dell'utilizzo di git c'è un team che lavora nella parte explore dei pacchetti quindi permette che ne so la ricerca o l'esplorazione alla ricerca appunto dei pacchetti e e delle repo nuove e interessanti c'è un team che lavora per gestire le community, le issues, le discussions quindi ti permette quelli che sviluppano tutto il codice riguardante a quella parte del progetto e c'è un team che si occupa delle actions quindi in realtà vedete è stato preso il progetto github e io non so se realmente lo slicing è fatto questo modo però dovendolo immaginare mi viene in mente così ed è stato diviso per ambiti per settori settori dei quali vengono sviluppate le varie funzionalità e quindi vengono messi in piedi dei sistemi che vanno a risolvere determinati problemi relativi appunto al settore e quindi è necessario fermarsi un attimo e provare a fare un focus sui team con l'approccio a microservizi quello che si andava a fare era che si andava a creare dei team specialisti quindi team che vengono raggruppati per tecnologie perché come vi dicevo prima sembra naturale far parlare frontender con frontender loro condividono parti comuni di codice, librerie framework, tool e quant'altro e e quindi si ha una divisione così per team specialistici una cosa che entra nel mondo del micro front-end è appunto la creazione di team chiamati anche cross funzionali quindi team reaggruppati per use case che hanno una visione completa della feature e che magari a livello tecnico producono non delle librerie stellari o del codice perfetto pur producendo del codice che non è un capolavoro di botticelli, producono delle feature molto più vicine in realtà a quello che serve al cliente quindi aiutano, diciamo, queste operazioni di delivery del valore verso il cliente in modo molto più pragmatico e molto più utentecentrico e questo visto che il nostro lavoro non è costruire dei pezzi fantastici e bellissimi di codice da osservare ma è quello di realizzare delle funzionalità che possano generare valore nel nostro utente diciamo che è un vantaggio mica da ridere naturalmente quello che bisogna fare adesso però è fare un ragionamento sulla feature ownership quindi il primo problema che abbiamo è quello di individuare la funzionalità e per individuare le funzionalità quindi diciamo i perimetri che servono per definire i appunto i range nella quale i nostri team devono lavorare ci viene in mente un concetto che rubiamo dal mondo del domain driven design cioè quello dei sottodomini.I sottodomini possono essere di diverso tipo ma non lo andiamo ad analizzare adesso però hanno una caratteristica molto specifica che hanno un contesto ben circoscritto se ritorniamo all'esempio che ho fatto di github beh a quel punto è molto facile io la divisione di team l'ho fatta in quel caso pensando appunto ai sottodomini sottodomini che però possono essere legati al business o legati ad ambiti tecnici.Quindi ci sono dei sottodomini per esempio che ha senso sviluppare in house con dei team con degli sviluppatori super skillati e dei team dove ci possiamo permettere di avere anche qualche junior in più e dei team che possiamo anche tranquillamente dare in outsourcing.Questa divisione in team ci porta a dover anche lato tecnico mettere dei recinti al nostro codice e questi recinti si dividono prevalentemente in due tipi la prima è un recinto di tipo page quindi ogni team possiede una pagina e all'interno di uno o più pagine all'interno di queste lavora in completa autonomia.Il secondo recinto è quello dei fragment, quindi ogni team possiede una porzione di pagina e all'interno di questa dovrebbe riuscire a muoversi in completa autonomia.Naturalmente in questo caso le sfide di tipo tecnico sono molto interessanti a partire dal concetto di integrazione.Infatti l'integrazione tra questi micro front-end è la parte più più affascinante, no? Dei gingilli.Quindi entriamo nel paese dei balocchi."E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Eccoci qua, stiamo entrando nel paese dei balocchi.Abbiamo nella mano destra il il concetto delle pagine gestite dai team.Nella mano sinistra abbiamo i fragment, quindi le aree specifiche, i blocchetti all'interno delle pagine divise in team.Quindi abbiamo due elementi diversi tra di loro che però hanno un'esigenza significativa e hanno l'esigenza di essere integrati tra loro.Nel contesto delle pagine è molto semplice fare l'integrazione tra pagine diverse fatte da team diversi questa integrazione può essere lato server o lato client se è fatta lato server lo facciamo semplicemente con il routing, i link mettiamo un link che manda la pagina gestita da un altro team, il contesto, il contesto è la pagina web quindi è completamente isolato l'uno dall'altro quindi i perimetri sono ben circoscritti non ci sono conflitti a questo punto il nostro utente se noi siamo stati bravi a utilizzare la stessa immagine coordinata e quindi lo stesso design system alla fine il nostro utente percepirà un unico flusso un'unica applicazione in realtà sono appunto due pagine gestite da team diversi se proprio vogliamo farlo in un modo migliore possiamo utilizzare dei sistemi di front end proxy può essere un nginx della situazione che serve a seconda del del pat nella nostra nel nostro url un micro front end che ho l'altro tenete presente che comunque il team che sviluppa quel micro front-end lo rilascia dal sviluppo appunto in produzione gestendo magari anche i server relativi a quel micro front-end per cui questo front-end proxy in qualche modo fa da porta d'ingresso che maschera la complessità che sta all'interno quindi una sorta di gateway che però ti permette di accedere a un front-end all'altro in modo del tutto trasparente tu non vedi qual è la divisione in team che sta sotto.Un'altra soluzione relativa appunto allo spostarsi da una pagina all'altra può essere applicata a livello front-end.A livello front-end utilizziamo un metaframework, possiamo utilizzare un metaframework che si chiama single SPI potremmo anche farlo a mano e cosa fa single SPI? semplicemente ci permette appunto di fare la navigazione tra front end diversi magari anche fatti con framework diversi e si occupa lui di gestire routing montare o smontare le app fatte appunto con con dei framework ci da tutta una serie di tool che ci permettono di andare a gestire tutta la lifecycle del framework che viene smontato o montato e tra l'altro tutta una serie di utilities che servono per wrappare le applicazioni fatte con un framework o applicazioni custom visto che noi basta che esponiamo un oggetto con tre metodi e poi lui lo monta tranquillamente all'interno della nostra pagina.Quindi in realtà il page routing può essere fatto in due modi e quindi abbiamo una serie di tool che ci permettono appunto di integrare le nostre pagine come elemento conseguente del lavoro di un team di Microfrontend.Nell'altra mano però abbiamo i componenti, i fragment, quindi i blocchettini, le caselline, i riquadretti all'interno delle nostre pagine web e anche qua possiamo fare adottare delle tecniche chiamate composition quindi di composizione per andare a costruire la pagina che verrà percepita come un tutt'uno dal nostro utente e che in realtà alla fine sarà appunto composta da elementi diversi di team diversi naturalmente anche qua la composizione può essere fatta client-side o server-side.Nel caso della composizione client-side la prima cosa che mi viene in mente, la tecnologia più semplice e stupida e anche bistrattata è quella dell'iframe, tra l'altro tecnica adottata nel player desktop di Spotify.Quindi ogni iframe contiene al suo interno la sua applicazione che verrà incastonata in uno spazio specifico della nostra pagina naturalmente con l'iframe, che si porta tra l'altro davvero una bruttissima reputazione, viene utilizzato in contesti dove l'asseo non è una priorità, così come non è una priorità la modifica, diciamo, rapida di struttura della pagina perché si porta a tutta una serie di problemi legati alle dimensioni dell'iframe, ma qua aprirei un capitolo molto lungo.alternative? beh possiamo caricare il contenuto di quel micro frontend utilizzando Ajax che si va a scaricare dei fragmenti di html e magari delle altre funzioni di javascript del css lo va a montare attraverso javascript stesso all'interno di un blocchetto della nostra pagina naturalmente qua rispetto agli iframe andiamo a perdere un po' di isolamento perché in realtà quando noi buttiamo dentro la nostra pagina il codice javascript, beh a questo punto questo può anche dell'html e css questo potrebbe interferire con diciamo la struttura della pagina host quindi della pagina che va a ospitare questo questo elemento che viene incapsulato questo fragment in nostro aiuto ci viene una tecnologia, tecnologia che di cui abbiamo già parlato su gitbar e ne abbiamo parlato neanche tanto tempo fa nell'episodio 34 che sono i web components fatti con il custo e custom element e lo shadow DOM ripeto vi do vi rimando alla puntata numero 34 per approfondire se vi fa piacere la particolarità dei web components è che sono universali quindi non dipendono da framework specifici e soprattutto sono facili da utilizzare e hanno una particolarità specie se questi web components sono sviluppati con una particolare API che si chiama shadow DOM in questo caso abbiamo tutti i vantaggi dell'iframe uniti ai vantaggi della chiamata Ajax per scaricare il web component perché? perché ogni web component se il codice viene generato all'interno di uno shadow DOM è completamente isolato quindi non va a interferire con il resto della pagina naturalmente abbiamo tutta una serie di tecniche di composizione lato server side quindi che vanno a servire questi fragment già compilati lato server e e possiamo partire dalle più vecchie funzioni di server-side include che web server come nginx mettono a disposizione passando per le edge-side include fino ad arrivare a tool un pochino più evoluti come taylor e podium faccio un pochino di l'introduzione a taylor e podium perché sono molto interessanti sono dei tool scritti in Node.js che servono in qualche modo per andare a esporre da una parte tutti questi fragment in modo che chi si occupa di integrarli li possa prendere.In realtà si comportano in modo un pochino diverso Taylor va a prendersi vari fragment e li monta su un template e di questi fragment viene esposto il codice html, il javascript e il css la stessa cosa fa Podium in un modo un pochino differente nelle note dell'episodio vi mando i link per andare a buttarci un occhio tenete presente che sono dei tool molto interessanti, Taylor è sviluppato da una società che sicuramente conoscete che si chiama Zalando ed è utilizzato produzione da Zalando che ha scelto di utilizzare una tecnica di composizione lato server proprio per andare a bypassare tutte le problematiche relative alla SEO.Podium è sviluppato dalla Subito.it norvegese se non ricordo male adesso il nome mi sfugge ma promesso ve lo metto nelle note dell'episodio e si occupa appunto di fare composizione lato server side quindi metterci a disposizione tutti i tool per fare la composizione delle pagine direttamente lato server e devo dire che in realtà poi andando a spulciare i dettagli Podium mi ha affascinato un pelino più di Taylor, però qua se avete voglia di approfondire l'argomento vi ricordo di iscrivervi nel gruppo Telegram e possiamo anche parlarne insieme.Quali sono le sfide allora che si aprono in questo contesto, specie nel contesto del fragment e poi in genere nel contesto di Microfrontend? una delle sfide è appunto quella della comunicazione tra micro front-end che possono essere sia gestiti con il page routing quindi dove ogni micro front-end è una pagina sia con la composizione.La comunicazione col page routing è molto semplice lo possiamo fare attraverso dei cookie o simili e attraverso i link per cui è necessario stabilire una interfaccia chiara per questi elementi un'interfaccia chiara e condivisa tra i team per questi elementi e questa deve essere una delle poche informazioni che noi condividiamo tra team e per questo la condivisione deve essere precisissima e ben documentata.Un altro tipo di comunicazione è quella che si deve andare a innestare lato client-side quando dobbiamo andare appunto a unire due fragment, le caselline sviluppate da team diversi all'interno di un'unica pagina.Immaginatevi come i famosi widget che andate copiate e incollate all'interno delle vostre pagine.A questo punto esistono tutta una serie di tecniche di integrazione attraverso l'uso per esempio dei custom element dove abbiamo un micro frontend che dispaccia sulla variabile globale window un certo evento e un altro component che rimane in ascolto di quell'evento e si comporta di conseguenza.Per cui abbiamo gestito la comunicazione in un contesto completamente disaccoppiato.Naturalmente di tecnologie che aiutano l'implementazione di micro front-end ce ne sono diverse.Non per ultima Open Components.Devo dirvi che sto provando a convincere Matteo Figus uno degli sviluppatori di Open Components per venire qua in trasmissione vediamo è una sfida vediamo se riuscirò a convincerlo adesso però volevo terminare l'episodio di oggi provando a fare un piccolo focus su vantaggi e svantaggi è arrivato la rovina.Pensavo di andare corto in questi episodi eppure mi sono dilungato tantissimo quindi cerco di passare molto veloce in questa in rassegna questa questa questa quest'ambito specifico è quello dei vantaggi e degli svantaggi.Quali sono i vantaggi di implementare i micro front end? Beh senza dubbio a livello di team e quindi il ritorno all'utilizzo di micro front-end come pattern organizzativo beh si riesce a rilasciare una funzionalità senza rimbalzi tra back-end e front-end, quei famosi ping pong che si tirano alle lunghe e dei meeting che non si fanno mai, si rimandano sempre.Quindi questa comunicazione viene in qualche modo, tutto questo processo di comunicazione viene bypassata andando a incentivare lo sviluppo della comunicazione in intra team che è più snella e più fluida altro vantaggio è che si evita il frontend monolith qual è il discorso? che fino a oggi col concetto di microservizi si aveva un unico monolitha lato frontend e tanti bei microservizi lato backend naturalmente si va appunto a dividere, frazionare, affettare questo monolitha per cui in qualche modo si vanno a realizzare tanti piccoli sistemi che sono autonomi anche nel deploy questo fa sì che in qualche modo si isoli il rischio ok? in ambito enterprise e specie quando la nostra applicazione scala rapidamente, beh isolare il rischio vuol dire ridurre il numero di errori e bug o quantomeno avere il controllo maggiore su errori e bug perché da sviluppatori noi siamo macchine genera errori contenere il rischio di una tecnologia sbagliata, una scelta tecnologica sbagliata.Questo è molto interessante proprio perché avendo dei blocchi di funzionalità limitate possiamo, se abbiamo sbagliato framework, possiamo permetterci di riscrivere il pezzo da capo in un ambiente contenuto e isolato dove il danno è veramente limitato, cosa che invece se avessimo sviluppato per interno la nostra applicazione sarebbe stata cosa impossibile naturalmente l'affettare la nostra applicazione in contesti crea degli ambiti molto più contenuti, le funzionalità sono più contenute e anche più spiegabili, quindi quando si va a fare l'onboarding di nuove persone queste persone diventano assolutamente produttive in slot di tempo decisamente inferiori.Immagina te di lavorare nel front end di ebay e di fare l'onboarding di un nuovo sviluppatore front end e devo raccontare tutto il front end di tutti ebay.È una cosa impossibile ma se a questo sviluppatore andate a raccontare il front end della funzionalità compralo subito questo sviluppatore, diciamo, diventerà produttivo in un lasso di tempo più contenuto avere una codebase più piccola permette un refactoring più agile quindi un codice più più più più più più più più mantenubile mantenibile penso sì che è così e avere una codebase più piccola naturalmente fa sì che il comportamento di quel blocco di codice sia più prevedibile e quindi si limitano anche gli errori come vi dicevo prima contenendo le dimensioni delle nostre varie codebase abbiamo la possibilità di cambiare spesso quindi in un ambiente dove esce un frontend a settimana avere la possibilità di switchare tecnologia limitando il rischio perché male che vada stai distruggendo una feature molto piccola, beh ci rende attrattivi verso il recruiting vi faccio un esempio se domani volessi decidere di sperimentare una funzionalità usando Phoenix, Elixir e Cassandra e magari Helm nel frontend, magari una funzionalità di e-commerce quindi basata proprio su approcci completamente funzionali potrei farlo tenendo magari tutto il resto della codebase in PHP e in React.In questo caso se dovessi fallire nell'esperimento non mando a monte tutto il progetto, ma semplicemente quella funzionalità e quindi posso gestirne.Naturalmente questo approccio può in qualche modo aiutare quando si va a approcciare Codebase Legacy.Questo perché in realtà ci permette di iniettare nella Codebase Legacy del nuovo codice scritto con approcci moderni magari immaginate una Codebase front-end di fatta con Angular 1.4 andate a iniettare degli elementi fatti con Angular 10 o React che sono scritti con un approccio moderno e gradualmente andate a svecchiare quel tipo di codebase naturalmente ci sono tantissimi altri vantaggi la cosa più interessante anzi una cosa che mi rende molto attraente l'approccio a micro front-end è che introduce un concetto spesso trascurato quando noi andiamo a sviluppare del codice, il poterlo sviluppare in un modo così autocontenuto e disaccoppiato, che sono delle modalità che ci vengono fornite da un approccio a Microfrontend, fa sì che noi pensiamo al nostro codice non solo ottimizzato per andare a fornire delle funzionalità, ma lo iniziamo a pensare anche in un'ottica di distruzione.Quindi andiamo a ragionare su tutto quello che è il ciclo di vita del nostro blocchetto di codice.Per cui quando lo andiamo a scrivere pensiamo anche "Oh ok, quando dovrò buttare questo pezzo di codice nel cestino avrò problemi in quali contesti mi troverò dovendolo strappare dal sistema generale, dall'ecosistema generale, a quel punto iniziamo appunto a ottimizzare il nostro codice anche per la destroyability, che è una mentalità e un ragionamento molto molto interessante.Naturalmente non tutto è gratis, anzi niente è gratis, è tutto a un prezzo.Qual è allora il prezzo da pagare per utilizzare i micro front-end? Beh, alert importante, se state facendo un progetto solo developer, un side project, probabilmente non è la soluzione che fa il caso vostro.Perché? Perché in prima cosa vi troverete davanti a un sovraccarico tecnologico.Quando noi sviluppiamo con i micro frontend andiamo ad aggiungere complessità alla nostra applicazione complessità che può essere contenuta se micro frontend l'integrazione la facciamo con i link o con gli iframe ma che scala velocemente quando inseriamo degli pezzi di codice che possono essere che ne so meta framework di integrazione come single SPA o tecnologie come taylor e simili che dobbiamo andare comunque a gestire per cui attenzione che dobbiamo stiamo inserendo complessità nel nostro sistema tra l'altro qual è però il vero problema che quando noi andiamo a sviluppare lato front-end cioè finché lavoriamo nel contesto di microservizi scalare è abbastanza semplice mi tiro su 10 container con un replica set e a quel punto sto scalando orizzontalmente senza troppi mal di testa ma come facciamo a scalare il front end? cioè le capacità del browser sono sempre quelle non è che vuoi dire metti i quattro browser in parallelo al tuo utente per vedere la pagina per cui dobbiamo anche pensare che la complessità che stiamo inserendo deve essere in qualche modo deve avere un corrispettivo lato potenza di calcolo del nostro utente e qua in realtà dobbiamo stare molto molto attenti.Un altro problema un altro svantaggio è che con i micro frontend viene promossa a piene mani la metodologia share nothing cioè ogni team deve evitare di condividere e deve evitare di condividere qualunque tipo qualunque cosa con gli altri team se non le interfacce di comunicazioni specifiche quindi magari ci troviamo a dover che ne so sviluppare due o tre elementi in ogni team che sono gli stessi quindi a questo punto dobbiamo anche buttare un occhio al carico di lavoro che è moltiplicato perché ogni team magari sviluppa leather, ma allo stesso tempo ha la ridondanza che vuol dire più spazio memoria più bug fix da fare.Certo possono essere marginali ma comunque dobbiamo fermarci e ragionare anche in quest'ottica.A Microfront End spero di essere riuscito a raccontarvi in questi pochi minuti in realtà ho visto che ci sono preso un po di tempo e spero di essere riuscito a raccontarvi un po quella che è il mondo dei micro front end diciamo dalla testa alla coda poi senza entrare troppo nei dettagli ma almeno a darvi una visione di insieme.I micro front end sono un mondo affascinante specie se ci si muove in ambiti enterprise dove si sta iniziando a sentire l'esigenza di scalare rapidamente dove i team crescono velocemente quindi se si sta sviluppando un side project non è la metodologia e l'approccio probabilmente adatto.Ripeto quando si parla di micro front end non si parla di tecnologia o almeno non solo, ma si parla più di un approccio organizzativo e architetturale.Quindi le sfide stanno su quel livello anche perché come avete visto i micro frontend possono essere implementati con i link e con gli iframe che non sono queste tecnologie super super affascinanti o super moderne.Detto questo però chiudiamo in questo momento il talk tecnico.Lo so oggi avete dovuto sopportare la mia voce e non quella di un ospite ma vi prometto che già dalle prossime puntate ci sono tutta una serie di ospiti molto molto interessanti quindi vi lascio un po la colina in bocca anzi se volete scoprire qualcosa di più aprite il vostro browser t.me/gitbar entrate nel nostro gruppo telegram e la butterò un po di di anticipazioni sulle sulle prossime puntate e nulla per il resto vi ricordo rapidamente i nostri contatti quindi telegram t.me slash github per iscriversi al gruppo telegram info@github.it per le mail e @brainrepo su twitter tutti gli episodi con le relative note degli episodi link e quant'altro li trovate su www.gitbar.it se l'episodio vi è piaciuto aprite il vostro client di podcast preferito e iscrivetevi naturalmente parlatene con amici e colleghi e se vi è piaciuto veramente tanto potete lasciarci una recensione ne abbiamo veramente poche anzi potrei dire su Apple Podcast ne abbiamo una quindi per favore lasciate le recensioni queste ci aiutano a a scalare un attimino nelle classifiche e a contattare più orecchie possibile quindi far crescere la nostra community e nulla, qua da Lione è tutto come chiudo l'episodio riaccendo il condizionatore che le temperature sono ancora molto alte detto questo noi ci diamo appuntamento la prossima settimana e nulla ciao GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.
