Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel bar degli sviluppatori.

L'inverno è quasi alle porte e io sono in compagnia di Luca.

Ciao Lu, come state? Ciao! Fa freschino, oddio è un tempo un po' pazzerello in questo periodo, perché fa fresco, caldo di nuovo, poi di nuovo freddo.

Infatti ho la felpa, ma ho caldo.

Aprirò la finestra? Va bene insomma, continuiamola con questo small talk.

Bando alle ciance, vi ricordo rapidamente i nostri contatti e poi possiamo partire.

Info che ho c'è la Geekbar.it per contattarci, at Brain Rapos su Twitter per contattarmi direttamente, oppure il nostro fantastico gruppo Telegram.

Dovevi dirlo tu, scusa Luca.

Abbiamo superato, sì dovevo dirlo io, ma pazienza, abbiamo superato i mille utenti, siamo anche sopra al 1010, 1016, adesso non lo so perché c'è qualcuno che scrive, e niente, il gruppo Telegram Geekbar Podcast lo cercate su Telegram e c'è il logo con il nostro buon Mauro e sotto la scritta Geekbar non potete sbagliare.

È bellissimo stare qua, erano quattro puntate che mancavo e niente, sono gasato.

E poi oggi siamo insubitamente più energici visto che sono le 10 del mattino, certo bene una birra con l'ospite a questa ora, tra l'altro da lui sono le nove, è un po' presto ma io direi che è arrivato il momento di iniziare.

Benvenuti su Geekbar, il podcast dedicato al mondo dei full stack debellator, i mezzo artigiani, mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.

Eccoci qua, eccoci qua, oggi è venuto a risalutarci un amico di Geekbar, uno di quegli ospiti che è venuto ai primordi quando abbiamo iniziato questa esperienza circa due anni fa e abbiamo di nuovo con noi Luca Mezzalira, serverless specialist o principal serverless specialist, questo ha più che un ruolo è uno scioglilingua su AWS.

Ciao Luca! Ciao a tutti, ciao, grazie per avermi qui di nuovo.

Grazie a te per essere venuto a sbevazzare alle nove del mattino con noi e a parlare di micro front-end e serverless, due topic dove sei il king.

Ma ti dico, king non lo so, sto cercando di fare il mio per divulgare le potenzialità delle due architetture, poi se ci riesco bene sono contento, dopo mi direte voi quanto bene ci riesco a coinvolgere la community.

Ci riuscirai tranquillo visto che sei un animale da palcoscenico e ti muovi facilmente su tutte, sui palcoscenici di tutto il mondo.

Io ricordo che tu insomma facevi tanti viaggi in giro per conferenze, eri super attivo e sei super attivo, ma come fai? Questa è un'ottima domanda, credo che il diciamo il fatto che secondo me è passione quella che ho più che altro, più che lavoro, mi permette di andare oltre le classiche otto ore di lavoro, nel senso che non ho nessun problema se devo viaggiare, andare dall'altra parte del mondo, fare talk, ma anche continuare a lavorare, andare avanti sulle cose che devo fare in AWS.

Perciò in generale ti dico, spesso e volentieri, molti mi chiedono ma come fai a fare tutta sta roba qua? Ti dico la mia ricetta è semplice, disciplina e organizzazione di solito aiutano molto, la passione on top di queste due caratteristiche aiuta a fare delle cose che sinceramente non mi sarei mai aspettato.

Tu viaggiavi tantissimo e viaggi tantissimo, la mia domanda è un po' particolare perché anch'io in quest'ultimo periodo sto viaggiando un po', riesci a lavorare barra studiare in viaggio? Perché quando viaggi per conferenze, dei enormi slot di tempo sono dedicati a stare nella lounge dell'aeroporto o sei in aereo, qual è la tua ricetta? Se riesci, qual è la tua ricetta per farlo? Guarda, io ti dico, adoro andare agli aeroporti e adoro studiare e lavorare in aereo, infatti per il reinvent di quest'anno a Las Vegas dovevo preparare due talk, uno di questi l'ho preparato in aereo mentre viaggiavo per Madrid due settimane fa, perché proprio non avendo distrazioni, non avendo spesso internet perché o funziona male o non c'è proprio, soprattutto nei voli europei, a me proprio va benissimo perché mi preparo a monte il giorno prima su qualcosa che posso fare offline, che magari è di, diciamo, posso ragionarci senza avere distrazioni di, che ne so, il messaggio su Slack o il tweet che mi arriva o la notifica che mi arriva sul cellulare.

So che ho due ore, tre ore, quattro ore dove non ho nessuna distrazione, posso focalizzarmi completamente e questo a me aiuta tantissimo.

Infatti c'è un bellissimo libro, dato che iniziamo con i suggerimenti, c'è un bellissimo libro che ho letto quest'anno che si chiama Deep Work e sostanzialmente spiega quanto potremmo fare di più se riuscissimo a concentrarci senza avere distrazioni.

Questo secondo me è una delle cose più vere che ho visto, o l'ho provata sulla mia pelle negli ultimi mesi e devo dire che mi trovo veramente bene ad approcciarli in quella maniera là, anche perché comunque Deep Work non significa fare otto ore di lavoro senza distrazioni, ma significa avere dei, che ne so, quelle due ore o tre ore, quei blocchi di tempo che sono totalmente dedicati a una cosa dove chiudi col mondo esterno e ti focalizzi su quello che devi fare.

E quello che puoi fare in due ore è fantastico, nel senso che spesso la tesi di questo libro è il fatto che siamo bombardati da social e da interazioni esterne e spesso ci dimentichiamo che lavorare anche due ore la mattina e due ore pomeriggio in isolamento su un certo progetto che devi fare ti può cambiare completamente la quantità di target che puoi avere.

Quindi devo dire che come approccio ha funzionato molto bene.

Questo è un problema proprio reale dei nostri tempi.

Sto notando che quando mi isolo per un motivo o per un altro, una riunione, una telefonata anche, o appunto qualche lavoro, guardo il telefono dopo un'ora e ho circa 120 notifiche di cose completamente inutili, dalle chat del calcio dei miei figli o della scuola o amici, parenti, eccetera, eccetera, alle notifiche push dei cellulari che guarda Twitter, guarda che cosa ha tweetato Tizio e Caio e lì penso, caspita, in un'ora ho ricevuto 100 notifiche, vuol dire che io quando non ho tutta questa pipeline ogni due minuti ho questa micro distrazione che devo gestire e che ovviamente appunto non mi fa lavorare.

Sì, è un po' un problema, secondo me, delle persone che lavorano nel digitale oggigiorno, nel senso che è molto vero che le distrazioni purtroppo sono dietro l'angolo, però non ci rendiamo conto di quanto ci rimettiamo a ritornare nel focus di un progetto.

Quindi il fatto che guardiamo un tweet 30 secondi, di solito quello non sono i 30 secondi che perdiamo, ma è molto di più, può essere anche commisurato in 10 minuti, 20 minuti, quello che è, perché rientrare nel flow, come viene descritto anche lì, è estremamente complesso.

Tant'è che io ho iniziato a usare, prima non lo usavo, fino all'anno scorso non lo usavo molto, la funzionalità di focus di Mac OS X, dei dispositivi Apple, perché sincronizza con tutti i tuoi account.

Quindi io so che non ricevo nessuna vibrazione sul mio smartwatch, so che non ricevo nessuna notifica sul mio cellulare e neanche sul computer, perciò sono completamente immerso in quello che faccio.

E questo mi capitava prima, spesso dopo cena, dove appunto avevo quelle due ore di tranquillità dove nessuno mi contattava, adesso invece riesco a ritagliarmi questi spazi durante le ore lavorative, che è veramente fantastico.

Sì, tra l'altro una cosa che ho notato è che il nostro cervello acquisisce dei pattern.

Faccio un passo indietro.

Quest'estate io ho lavorato alla Casa al Mare per circa un mese e mezzo con mia moglie e la bambina.

Ok, mia moglie non capisce bene che cos'è il lavoro da casa, il remote working, e quindi ogni due per tre ti interrompe e poi la bambina ti interrompe e alla fine mi sono reso conto, tornando qua a Lione dove invece poi mia moglie va a lavoro, mia figlia va all'asilo, che quel pattern di interruzione, di focus, di concentrazione mi è rimasto.

E adesso sto faticando per rimanere concentrato più di 15 minuti e sono qua già un mese e mezzo, quindi non è solo il momento in cui ricevi un messaggio, ma è proprio quello schema di gestione della concentrazione che poi ti rimane impresso e diventa difficile da modificare.

Totalmente d'accordo.

È incredibile.

Adesso che l'hai detto lo sto notando anche io, grazie.

No, sì, io infatti proprio ieri sera ne parlavo con William, la decisione è stata quando tu sei a casa, sai che c'è la porta chiusa, sono in momento di focus, qualunque cosa succeda non mi disturbare perché altrimenti diventa impossibile la necessità di settare delle regole chiare da quel punto di vista è importante proprio per tenere il focus.

Regole chiare che devi settare anche con te stesso e soprattutto con te stesso.

Passiamo però ai micro frontend, Luca.

Tu due anni fa sei venuto qua su Gitbar e ci hai introdotto l'argomento.

Cosa è cambiato da due anni a questa parte nel mondo dei micro frontend? Tutto no, però è cambiato tanto.

Nel senso che due anni fa eravamo proprio agli albori, nel senso che sì c'erano delle aziende che l'avevano abbracciato e sì c'erano degli sviluppatori che ne parlavano, ma c'era moltissima disinformazione e comunque non c'era un'adozione secondo me abbastanza mondiale.

C'erano delle aziende che avevano fatto un po' da precursori ma non era ancora sdoganato come concetto.

Oggi devo dire che ho la fortuna di aver parlato con decine di clienti a livello mondiale, dalla Nuova Zelanda a Silicon Valley, riguardo a questo pattern architetturale e sto vedendo che ci sono fior fior di aziende che lo stanno abbracciando e stanno contribuendo anche a rendere più concreto l'implementazione di micro frontend.

Ci sono aziende, tanto per nominarle alcune, come Netflix, PayPal, American Express, poi ci sono aziende più locali tipo aziende grossi assicurazioni e banche sparse per il mondo che lo stanno abbracciando.

Cioè tutte quelle aziende che oggi giorno stanno utilizzando i microservizi è probabile che abbiano bisogno anche di micro frontend, più che altro perché entrambe queste architetture distribuite risolvono un problema organizzativo più che tecnico.

Nel senso che sì, ci sono dei benefit tecnici assolutamente, ma quello che l'adozione porta è quello che viene chiamato l'agilità per un'azienda di poter modificare parti dell'applicazione da API fino al frontend in maniera autonoma e diciamo ridurre il rischio di dover ogni volta mandare in produzione del codice che devi ritestare da punto a capo.

Invece andiamo atomicamente a cambiare delle porzioni del nostro sistema e diventa tutto molto più semplice perché è molto più modulare.

Chiaro, oggi quanto hai visto micro frontend adottato per come dici tu, per una questione di tipo meramente organizzativo più che tecnico e quanto invece e quali possono essere le esigenze alla base di natura tecnica che possono spingere all'adozione del micro frontend? Cioè esistono delle esigenze tecniche che ti dicono adotta micro frontend o il driver è sempre gestionale e organizzativo? No, allora diciamo che ho parlato con molti sviluppatori e anche startup che vogliono abbracciare micro frontend.

Il problema secondo me che non ci rendiamo conto è che spesso quello che la gente vede nei micro frontend ma nello stesso per i microservizi non è tanto l'architettura che gli interessa ma sono i benefit che gli interessano.

Quindi il fatto di poter indipendentemente mandare in produzione una porzione dell'applicativo o il fatto di poter lavorare su una porzione di codice senza andare a creare, introdurre bug su altre parti dell'applicazione.

Cioè questi sono i benefit che loro stanno guardando.

Il problema che spesso non ci rendiamo conto e che oggigiorno è più mitigato rispetto a due anni fa è che comunque c'è un uno sforzo adizionale nell'utilizzare queste architetture perché tutta la parte di come gestire i flussi di lavoro, come gestire le automazioni per il deployment su produzione, su staging e tutti gli altri environment che uno può avere è un effort maggiore di un'applicazione monolitica.

Ora tecnicamente io vedo che stiamo evolvendo parecchio sul mondo micro frontend nel senso che prima dovevi farti molte più cose per i fatti tuoi e quindi dovevi crearti all'interno della tua azienda, i tuoi tool e via dicendo.

Oggigiorno diciamo abbiamo risolto alcuni problemi chiave quindi se penso tutta la parte di composizione con single SPA o con module federation diciamo che abbiamo una developer experience che è già più semplice e più azzeccata.

Il problema è che quella è una porzione di tutta la complessità che i sistemi distribuiti portano.

Quindi secondo me ti dico spesso e volentieri, parlavo anche ieri con un collega, si diceva c'è un'azienda di 300 utenti che è una startup, ci sono tre sviluppatori che vogliono lavorare con microservizi e micro frontend.

E lì appunto dicevamo sì ma qual è il vantaggio nel senso ok magari un giorno diventeranno l'unicorno che avranno 3 milioni di utenti ma in quel momento lì ci sarà un altro tipo di panorama e quindi i sviluppatori saranno molti di più e cambierà completamente il modo in cui saranno strutturati.

Perciò ha molto più senso iniziare cercando di capire qual è il contesto piuttosto che anticipare qualcosa che magari non accadrà mai o accadrà in una scala che non è di un anno ma di dieci anni, quindi è una crescita organica dell'azienda.

Secondo me spesso sottostimiamo il fatto che alla fine quello che in realtà la gente vuole è modularità e modularità oggigiorno sul mondo frontend si può tranquillamente avere anche con un'architettura monolitica.

Qual è il problema? Che andiamo a delegare agli sviluppatori l'implementazione corretta di design pattern e di encapsulation e di tutte le altre caratteristiche di sviluppo software invece che delegarla con dei artificial boundaries che sono sostanzialmente fisici, quindi io ho un file che è staccato da un altro quindi sicuramente non va a intaccare.

Quindi da un lato andiamo a spostare la complessità dal fare una complessità implementativa di design pattern, di scrittura di codice, invece a una strutturale, quindi la parte di automation, della parte di come andare a definire il deployment, come andare a implementare soluzioni come canary release, blue green deployment, nella parte di produzione.

Quindi ci sono una serie di complessità che invece di essere applicate a livello codice che andiamo a ridurre la complessità vengono applicate a livello infrastrutturale e lì spesso casca il palco perché soprattutto nelle startup c'è il problema che non tutti hanno una conoscenza così ampia di queste soluzioni quindi si accrocchia qualcosa e dopo alla fine si va a dire ah no ma i micro frontend non funzionano.

Però in realtà non è che sono i micro frontend di per sé che non funzionano, è che non si è investito perché giustamente una startup deve generare valore il prima possibile, non si è investito sulle parti che invece sono quelle che rendono i micro frontend una soluzione estremamente fruibile e quindi tutta la developer experience e la parte di automazione.

Parlavi di startup e la cosa mi ha fatto ragionare, intanto è vero quando si adottano micro servizi barra micro frontend stai introducendo un layer di complessità aggiuntiva e se lo utilizzi con una certa disciplina riesci davvero a fare cose bellissime e super funzionali e altrimenti finisci con una serie di micro frontend monolitici perché magari sono accoppiati perché è mille problemi e ti viene questo mostro a sete teste che è difficile da domare.

Hai parlato dell'ambiente startup che è il posto dove questo tipo di condizioni si verificano più spesso, vuoi perché c'è e c'era adesso un po' meno una hype gigante in questo settore? No, micro frontend siamo fighi perché utilizziamo i micro frontend qua e là poi c'era un unico sviluppatore che si faceva micro frontend da sola a quel punto.

Fate una domanda figlio mio perché un problema ce l'hai tu e non il tuo codice.

Detto questo la mia idea è proviamo a ragionare sul concetto del micro frontend con uno sviluppatore da solo perché ci riflettevo ieri sera, esistono dei casi in cui quest'approccio è utile che è per esempio con la migrazione di codebase, refactoring di codebase esistenti utilizzando quello che si chiama lo strangler pattern cioè includiamo delle codebase esistenti per andarle praticamente a soffocare dal codice nuovo fino a farle sparire.

A livello strategico di implementazione esistono degli approcci più funzionali di altri per risolvere questo problema che è di natura meramente tecnica alla fine? Sì, le migrazioni secondo me sono sempre interessanti perché possono essere applicate in diverse maniere.

Non credo che sia solo il micro frontend che possa offrire questa possibilità nel senso che prendiamo per esempio se ho una single page application e la voglio trasformare con static site generator quindi magari next o gatsby, quello che preferite e vogliamo andare a ridurre, delegare molto di più al framework e avere molto meno da sviluppare in questa situazione.

Se per esempio vogliamo fare una migrazione del genere, spesso e volentieri diciamo possiamo partire dalla parte infrastrutturale nel senso che un'idea che mi venne nel lontano 2018 per fare una migrazione simile a questa però era da single page application micro frontend era utilizzare, diciamo intercettare la richiesta dell'utente e andare a fare il shift di traffic tra la versione vecchia e la versione nuova e lì sostanzialmente l'avevamo fatto usando CloudFront e Lambda di Edge e ci permetteva sostanzialmente di avere un piccolo, diciamo una lambda che sostanzialmente è un container che viene gestito direttamente dai AWS quindi l'unica cosa che ti focalizza la parte di codice e sostanzialmente quello che faceva era aggiungere un po' di codice per capire qual era la richiesta basata sul path dell'utente e basato su quella avevamo delle regole dove diceva vai sull'applicativo single page application o vai sull'applicativo nuovo e una cosa del genere è totalmente applicabile e oggigiorno molto di più di ieri con quando si ha una CDN che ha un po' di funzionalità come appunto avere la possibilità di avere compute prima che si raggiunga il file da poter servire al client e questo approccio qua secondo me è molto elegante perché non va a modificarti il codice che devi scrivere.

Molto spesso so che front end developers cercano di creare un application shell quindi un contenitore che fa lo switch direttamente sul client il problema va beh uno è di sicurezza nel senso che chiaramente tu devi avere tutto il codice che spiega quale path è nel vecchio mondo e quale path è nel nuovo mondo e già questo può creare delle sfide e l'altra cosa è che hai del codice che è una certa devi gestinare quindi sostanzialmente c'è più rischio che vai a introdurre dei bug e che hai degli edge case quando in verità se tu hai il codice come dovrebbe essere nel futuro ma vai a solamente gestire il traffico a livello di infrastruttura questo diventa molto più più semplice da gestire perché al momento non ti serve più e sei completamente nel nuovo mondo cancelli quello la lambda di edge quello che ti serve e servi il traffico normalmente quindi credo che questa sia diciamo una delle potenzialità poi chiaramente ci sono mille possibilità a livello architetturale per risolvere questo problema bisogna capire quali sono i trade off che siamo disposti ad accettare perché alla fine ogni scelta architetturale è alla fine basata sul trade off quindi ci sono dei pro e dei contro e quindi se i pro sono maggiori dei contro allora probabilmente sceglieremo una un approccio rispetto che un altro.

Sì guarda l'altro giorno parlavo al Leonjs con un ragazzo che lavora ad essere un medico per una qualche banca o assicurazione qua, una gruppa ma e loro hanno un approccio a micro front end ma hanno fatto un design system e quindi un UI kit condiviso adesso il loro problema è che utilizzano una pletora di framework ok quindi abbiamo micro front end con framework diversi che utilizzano un design kit che deve essere condiviso e quindi deve essere fatto che ne so in web components magari con stelcil e abbiamo una roba tipo un rombo dove abbiamo l'accesso centrale poi al centro abbiamo tutti i framework che convergono nella parte bassa sullo stesso UI kit.

Come vedi questo approccio? Come genera complessità e secondo te difficile da gestire? Quali sono i limiti di un approccio di questo tipo se esistono? Sicuramente esistono dipende che cosa quali sono le caratteristiche architetturali che volevano usare per specificare implementazione.

Di solito io sconsiglio di andare multi framework a meno che non ci siano delle ragioni particolari nel senso se per un breve periodo tipo parlavamo prima della migrazione da un'applicazione a un'altra quello secondo me ha senso perché sai che penalizzi il tuo utente per un certo periodo di tempo ma in un certo senso lo mitichi questa penalizzazione perché gli dai delle funzionalità nuove o magari un look nuovo alla user interface.

Il problema di ottimizzare per multi framework è che ti porti dentro...

uno aggiunge diciamo più complessità verso l'utente perché magari se abbiamo una pagina che contiene react view ai 60 kilobyte più o meno di framework senza alla fine dare nulla all'utente.

All'utente non gliene frega niente che utilizzi il framework più figo che ci sia su frontend.

Quello che gli interessa è riuscire a fare un'azione che spesso ci dimentichiamo purtroppo.

Quindi ti dico secondo me l'ottimizzare per multi framework è un po' una questione di litigare un altro problema che c'è all'interno organizzativo spesso che è una questione di pigrizia sulla coordinazione dei team.

Quindi sostanzialmente loro dicono spesso e volentieri ho visto aziende che dicono no ma noi facciamo così perché così tutti gli sviluppatori possono fare quello che vogliono.

Il problema reale è che non è solo una questione tecnica appunto che vai a diciamo a impattare sull'utente però anche organizzativa nel senso che se tu pensi ok un'applicazione dove c'hai react, angular e view nella stessa applicazione tu stai portando visioni differenti che sono fatte dall'esterno all'interno dell'azienda quindi tool differenti quindi ti stai portando una community differente.

Nel momento in cui, e questo è normale, uno sviluppatore o un team sparisce e qualcun altro deve prendersi in mano un altro framework che non conosce e lì inizia a essere un delirio perché dopo c'è la frustrazione degli sviluppatori, i sviluppatori lasciano, cioè c'è un impatto a livello aziendale che secondo me spesso ci dimentichiamo ed è un problema perché probabilmente le persone che appunto hanno permesso questa cosa qua non hanno pensato nel lungo termine e ti dico a me era successo ancora nel lontano 2016 quando era in The Zone dove avevamo loccato le tecnologie che si potevano utilizzare tipo anche sui microservizi dove c'è molta più libertà e abbiamo visto esempi come Netflix che hanno utilizzato una costellazione di linguaggio e programmazione ma hanno avuto questo problema nel lungo cioè quando c'è un'applicazione che non deve essere sviluppata per un anno e poi buttata via ma è un'applicazione che viene mantenuta negli anni queste considerazioni secondo me devono essere fatte a monte e capire anche la complessità di cosa ti stai portando in casa perché non è solo un aspetto tecnologico, ripeto, è community, scuole di pensiero, potenzialmente anche mercato perché sicuramente è molto più probabile che riesci a trovare un React developer oggi che un Vue developer e quindi ci sono una serie di considerazioni che vanno al di là della parte tecnologica che purtroppo bisogna pensare e spesso e volentieri non si ha la sensibilità di guardare nel lungo ma si guarda nel breve a dobbiamo deliberare facciamo questo parco giochi per sviluppatori che possono utilizzare quello che vogliono e poi ti dà l'utente e vabbè si vedrà.

No, stavo pensando proprio all'analogia tra i microservices e i micro front end perché appunto ai microservices hai più libertà di scegliere la tecnologia per una tecnologia adatta a quello che devi fare non una tecnologia come detto parco giochi del team di sviluppatori mentre invece nei micro front end si tratta comunque l'output è quello si tratta di renderizzare una pagina fruibile dall'utente quindi si tratta di creare un bottone creare un form creare delle immagini qual qual diciamo lì è proprio l'output il problema che si vuole risolvere è lo stesso quindi non ha molto senso.

No, sono d'accordo ma c'è un problema addizionale sui micro front end che non hanno i microservizi perché i microservizi di default vivono in dei limiti ben specifici che sono il container o la lambda function o quello che è.

In micro front end no perché come dicevi tu puoi ritrovarti che e ci sono state aziende che ho con cui ho parlato che avevano una parte in view e una parte in react che vivevano nella stessa pagina e nel momento in cui qualcuno per sbaglio si va a fare va aggiungere delle variabili nello scope globale eccetera e qualcun altro fa l'override e lì iniziano iniziano le complessità e dopo devi capire se non hai abbastanza diciamo se non sei abbastanza esperto nel fatto di gestire la parte di observability propriamente per la parte di micro front end rischi che diventa un casino e dopo il problema è ma sono i micro front end che mettono che fanno confusione.

Secondo me spesso e volentieri c'è questa questa cosa che ci dimentichiamo e spesso sento il parallelismo microservizi e micro front end sotto questo punto di vista qua però ci dimentichiamo che l'output è differente cioè uno esporta un api che spesso volentieri è json e quindi va bene fin tanto che sono totalmente disaccoppiati l'unica cosa vanno a comunicare in maniera standard quindi utilizzando json o quello che è dall'altra parte invece dobbiamo avere un output di che è standard ma il problema è che è tra virgolette couple perché vivono lo stesso scope.

Volendo fare un'analogia potremmo dire due microservizi con lo stesso database? Più o meno sì più o meno possiamo arrivare a pensare a quello però il vero rischio secondo me è che c'è una parte di educazione che dobbiamo ancora fare sulla parte di distributed architecture per la parte di user interface che ci vorranno anni cioè se io penso ai microservizi che comunque stiamo parlando di più o meno inizio 2000 quando abbiamo iniziato a vederli in maniera pesante e ancora oggi sentiamo di horror stories o storie dell'orrore che succedono nelle aziende non mi sembra diciamo che siamo così lontani anche sul front end chiaramente c'è ancora tanto da studiare la cosa che mi spiace un po' è che non capitalizziamo dagli errori fatti dagli altri io spesso quello che faccio è sapendo quello che succede nel mondo dei microservizi adattarlo nel mondo front end e riproporlo al front end di valore in una chiave che magari viene presa meglio però spesso e volentieri ci dimentichiamo ci sono state centinaia se non migliaia di sviluppatori che hanno già passato le pene che abbiamo passato sulla parte che stiamo passando sulla parte front end e non capitalizziamo quello che hanno sbagliato.

Esatto io negli ultimi mesi stavo facendo uno studio abbastanza approfondito sul sul cognitive load legato al nostro lavoro tu hai parlato di cognitive load legato al fatto di utilizzare più framework in un'approccio a micro front end voglio però shiftare un attimo questo ragionamento e provare a fermarmi un secondo su un caso.

Si è fermato proprio nel vero senso della parola.

Un secondo.

Proprio è anche più di un secondo va bene.

Beh in attesa che Mauro Mauro ritorni volevo soltanto mi permetto solo di dare un avviso visto che abbiamo visto che abbiamo citato un po' l'inclusione di framework e librerie diverse se dovete includere jQuery fatelo per riconoscenza e solo per riconoscenza non ci sono altri motivi in questo caso non so se se mi confermi.

Oggigiorno direi che jQuery ha dato quello che doveva dare ha spinto quello che doveva spingere adesso grazie a Dio ci sono queste sono una storia che deriva da ormai a un annetto di tempo per il quale motivi di usare jQuery è sicuramente la riconoscenza per tutto quello che ha dato infatti magari ogni tanto includetelo e fate un query selector così fategli fare questo e basta.

Sono tornato.

Ovviamente è uno scherzo ma vado via io e vi ritrovo a parlare di jQuery aiuto che succede.

Mauro vedo che parli ma non ti vediamo e non ti sentiamo.

Pronto pronto pronto.

Vedo che sta imprecando adesso.

È dal simbolo che vedi sulla traccia audio.

Ho riconosciuto il pattern dell' imprecatorio.

Mi sentite? Adesso sì.

Ah fantastico.

Dicevo vado via un attimo e vi trovo a parlare di jQuery che succede? No la mia domanda rispetto al cognitive load era poniamo caso in cui si utilizzi lo stesso framework.

Noi come Luca ci ha anticipato e ci ha detto in modo molto chiaramente Microfrontend è prima un pattern organizzativo più che tecnico o prima ancora di essere tecnico.

La mia domanda è dividendo un'autonomia legata allo scope, al contesto del Microfrontend e relegando un minimo di autonomia a questi team non si rischia in realtà di perdere il valore della consistenza all'interno della codebase? Cioè non solo framework c'è anche il concetto di che ne so regole dell'inter o di Prettier piuttosto che come risolviamo questo tipo di problemi usiamo una mappa o facciamo un cicloforo.

Adesso sto banalizzando però questo tipo di approcci alla consistenza aiuta poi nell'esplorazione e nella lettura della codebase da parte di chi non la conosce e quindi semplifica l'onboarding tra le tante cose semplifica anche l'onboarding che è uno dei problemi in realtà che la nostra industria ha.

Sì ti dico quello l'ho vissuto di prima pelle e diciamo che cambia un po' la cosa.

Allora la consistenza dipende come vai a gestire la parte implementativa del Microfrontend.

Per esempio in the zone avevamo lasciato scegliere agli sviluppatori che tecnologie volevano utilizzare quindi ho detto prima di dirmi usiamo questo usiamo quello perché poi ce lo terremo per un po' di tempo cerchiamo di capire che cosa abbiamo bisogno quindi gli ho detto guardate questo è quello che io voglio vedere a livello di architettura quello che scegliete sono problemi vostri quindi hanno fatto una serie di spike per capire le differenze tecnologiche per riuscire ad arrivare a quella parte implementativa e alla fine in maniera organica hanno deciso di andare con React e MobX.

Io personalmente sono un grande fan di MobX quindi mi è sempre piaciuto come come state management e quindi hanno hanno deciso quello e pian piano è stato preso da tutti i team che stavano arrivando quindi questo è stato il primo team che voleva fare Microfrontend e poi pian piano hanno spiegato come funzionava gli altri hanno visto il perché si era scelto certi framework e poi chiaramente ci sono state delle delle discrepanze implementative però non erano folli e qui ricado nel concetto che dicevamo prima nel senso il fatto di dar la possibilità a tutti di scegliere una tecnologia differente ha anche questo diciamo problema che è quello del longboarding.

Nel nostro caso l'onboarding era estremamente quando avevamo un team esistente e arrivava un nuovo sviluppatore nel giro di almeno di un mese aveva già codice in produzione perché uno c'è molta meno cose da dover sapere anche se l'implementazione è differente tra i team c'è molta meno roba da sapere e due quando si muovono da un'applicazione a un altro che quello succedeva più raramente perché dopo diventavano esperti del dominio e quindi ci tenevano anche ad avere il loro la loro volontà e il loro modo di vedere la parte di business rappresentata a livello di codice.

Quindi ti dico la parte di onboarding se viene utilizzato microphone 10 propriamente quindi si pensa a queste casistiche queste cose che sono al di fuori come puoi vedere della parte tecnica secondo me sono totalmente gestibili.

Lo stesso problema però te lo posso dire anche sui microservizi forse più accentuato perché sui microservizi poi diciamo c'è anche lì noi avevamo scelto Node e Go come linguaggi e avevamo forzato la mano su questi due principalmente ci serve uno a alto livello e uno a low level per certi microservizi e poi lasciavamo alle persone scegliere se Fastify, se Express o quello che è.

Lì è stato organico però la complessità di imparare qualcosa che è estremamente piccolo e non dover...

è vero quello che dici che voglio avere diciamo coerenza a livello di base di codice ma se è come io creassi molteplici applicazioni indipendenti il codice non dista in maniera diciamo non dista troppo tra una e l'altra.

Il problema dell'onboarding viene risolto molto rapidamente quindi quello mi preoccupa meno.

Mi preoccupa molto di più nella situazione multi framework perché se io passo da React a Vue e questo credo che è un'esperienza che abbiamo avuto tutti c'è un onboarding molto più ampio perché non ti cambia solo quello che scrivi ti cambiano le implementazioni, l'architettura dietro al framework e quindi è molto più complesso la gestione dell'onboarding che deve avere una persona che viene da React e va a Vue o viceversa.

Vero, verissimo.

Proprio stanotte ho ripreso in mano una codebase Vue, mi sono sentito un completo idiota dopo due anni che...

no un anno...

ma che cosa sto dicendo? Sette mesi che uso solo React.

In realtà questo attrito è pesante posso posso confermare.

Abbiamo parlato di micro frontend però come si dividono i micro frontend? Io ho il mio user journey, il percorso che deve fare il cliente per raggiungere la sua meta, come la fetto questa strada? Diciamo che sapere lo user journey aiuta perché ti dà delle indicazioni su come l'utente utilizza l'applicazione.

Un'altra cosa che purtroppo non è sdoganata abbastanza, non solo sul frontend ma anche nel back end, è il concetto di domain driven design.

Cioè una delle problematiche che domain driven design risolve è il fatto di cercare di avere dei meccanismi che permettano la parte di business a parlare con la parte tecnica.

E' lì dove il problema di solito...

dove casca l'asino come diciamo in italiano.

In quanto nel momento in cui capisci quello che il business si aspetta e come gli utenti utilizzano il tuo applicativo diventa molto chiaro dividere l'applicazione in esperienze d'utente e poi potenzialmente cambiare l'aspetto organizzativo in maniera tale da avere questa riflessione della parte tecnica sulla parte organizzativa.

Perché queste due cose purtroppo l'architettura e la parte organizzativa non possono essere disaccoppiate.

Spesso e volentieri noi prendiamo tecniche e architetture da altri da altre aziende dicendo ah ha risolto questa cosa in AWS o qualsiasi altra azienda, la applichiamo alla nostra e non funziona.

Questo perché non è solo un problema diciamo tecnico ma è anche culturale.

Quindi nel nostro caso nel frontend dobbiamo iniziare a capire come vanno utilizzate come vengono utilizzate gli utenti e capire anche quali sono le diciamo le parti che in domain driven design vengono chiamati sottodomini.

Ogni sottodomini sostanzialmente è una porzione di logica che rappresenta nel nostro caso un'esperienza utente.

Un esempio pratico se pensiamo a Netflix, Netflix può essere spacchettato in che ne so in page che probabilmente avranno un certo tipo di traffico.

A una certa però la gente dice ah ma non mi interessa quello che c'è Netflix quindi non vado avanti.

Quindi quella parte lì potrebbe essere un primo sottodominio.

Poi vado nella parte di onboarding e lì c'ho l'utente che è già autenticato ma non è autenticato su quel device e l'utente che deve sottoscriversi e questi sono altri due user journey completamente differenti.

E poi vado avanti con l'applicazione.

Quindi posso iniziare a separare queste cose.

L'altra cosa che devo fare è partire più ad alto livello e poi andare più nel dettaglio per dover spacchettare i miei mic front end in parti più piccole.

Perché qual è il problema? Che quando noi andiamo già a monte a cosa che vedo spesso, a copiare il concetto di mic front end a un componente stiamo sbagliando completamente il modo in cui stiamo dividendo l'applicazione.

Perché non partiamo da un punto di vista del business quindi utente ma partiamo da un punto di vista tecnico e quello che noi andiamo a fare è sostanzialmente creare coupling tra componenti perché è inevitabile per la natura del componente è inevitabile che ci sia coupling tra il contenitore del componente e il componente stesso.

E in questo caso è distribuito quindi è ancora più complesso perché tu hai un team che ha un componente distribuito, un altro con il componente distribuito e devono coordinarsi per deployare.

Il mic front end non deve coordinarsi per deployare perché è più coarse grain quindi è più diciamo, copre più area e quindi in quel caso lì ha la logica che è totalmente embeddata all'interno.

E questa cosa qui spesso e volentieri ce la dimentichiamo oppure non non non la sappiamo e questo è un grosso problema questo è quello che viene chiamato da Frederick Brooks accidental complexity quindi quella complessità che è accidentale per mancanza di conoscenza.

Ed è essenziale secondo me che iniziamo dopo aver capito com'è l'esperienza utente come potremmo dividere i nostri i nostri mic front end, riflettere questa questa divisione nei team perché se abbiamo fatto un buon lavoro e c'è una divisione che è uno a uno e partendo da diciamo dei pezzi più grossi e poi andando più in maniera più dettagliata se serve diciamo che siamo nella buona strada.

Non esiste e ripeto non esiste una maniera per poter perfettamente dividere un sistema distribuito al primo colpo quindi bisogna andare a tentativi bisogna iterare spesso in questa soluzione e questo vale per i microservizi e vale per il mic front end.

Quindi non c'è un modo per dirti a questo è l'euristica che ti permette di farla in qualsiasi modo non esiste questa cosa qua bisogna capire il contesto e quello che funziona oggi nella tua azienda probabilmente non funzionerà nella prossima dove andrai quindi è importante però che abbiamo delle delle metriche delle linee guida tra cui appunto il fatto di partire più a ampio spettro e poi pian piano andare a dividere se necessario perché nel momento in cui dopo inizia a farti le domande ok ma se noi abbiamo questi due pezzi che sono nella stessa pagina che rappresentano domini simili però in realtà sono gestiti da due team e devo coordinarmi ogni volta che devo devo deploiare allora probabilmente stiamo facendo qualcosa di sbagliato cioè il fatto in cui andiamo a disegnare l'applicazione è sicuramente il traffico come viene gestito alla parte di visualizzazione degli utenti la parte organizzativa e poi quello che vuole raggiungere il business queste tre cose mixati insieme vi danno uno spettro di andare verso una direzione che vi permetterà di lavorare bene e questo è chiarissimo per come l'hai spiegato la mia domanda è come Evans ci insegna parlando di domain driven design uno dei veri problemi del DDD è fare in modo che i contesti siano ben isolati e abbiamo lo stesso problema col front end il problema è che i micro front end devono anche poter comunicare tra loro quali sono nella tua esperienza e da quello che hai sentito in questi anni di lavoro sui micro front end le strategie le varie strategie per permettere la comunicazione tra micro front end comunicazione tra micro front end è uno degli scogli iniziali che tutte le aziende hanno perché spesso e volentieri e ci sono aziende che lo fanno con successo utilizzano uno state management che è condiviso problema di quello è che in micro servizi viene definito design time coupling in quanto tu non fai a fare un qualcosa che a livello tecnico è totalmente fattibile ma non ti rendi conto delle problematiche che vai a creare l' organizzativo quindi nel momento in cui condivido una porzione chiave perché è il modello alla fine della mia parte front end ogni volta che modifico il modello in maniera sostanziale tutti quelli che si riferiscono a modello devono ritestare le cose devono andare a gestirsi i two village case come viene gestito come sono stati i cambiamenti riflettere nella loro base di codice quindi tu vai a fare un coupling da livello di design di del modello con le varie ui questo per me è abbastanza complesso e non può e non deve essere perché nel lungo termine questo lo si paga soprattutto quando si hanno il giro di sviluppatori che è una certa lascia un'azienda sposto in altri team e arrivano gli sviluppatori nuovi che non capiscono completamente il dominio e quindi vanno a rischiare quello che io di solito suggerisco è invece essere più indipendenti quindi anche perché design time coupling porta anche dipendenze e dipendenze esterne per il deployment quello che io suggerisco invece è avere uno state management per micro front end magari condividere la libreria che si utilizza quando si hanno molti apici micro front end nello stesso avvista e utilizzare invece un pub sub pattern che è publici subscribe pattern che siamo abbastanza familiari con l'observer pattern e via dicendo nel mondo front end si utilizzava quando io avevo vent'anni e anche prima e estenzialmente vi permette di disaccoppiare perché l'unica cosa che fate è io mando un evento qualcuno se se lo vuole pigliare se lo piglia ma quello non è un problema di chi del producer quindi chi emette l'evento e secondo me questo approccio qui è io ho visto in pratica in pratica su parecchi clienti ho visto quanto beneficio porta soprattutto sul fatto che adesso il mio team l'unica cosa che deve fare è mantenere un una lista di eventi che il mio micro front end riceve in input e riceve in output questo significa che la mia parte di documentazione è estremamente leggera perché di solito un micro front end non manda milioni di eventi all'interno di un'applicazione ma soprattutto mi permette di avere un modo che se devo fare una breaking change e per favore cercate di non farla vi permette di comunicare a livello di contratto con chi va a consumare l'evento e chi va a produrlo e questo è un ottimo modo per iniziare una discussione diciamo positiva sull'implementazione perché dopo se abbiamo una cosa condivisa chiaramente tutti stanno pensando a come vanno a implementare la parte futura delle loro funzionalità ma se invece abbiamo una cosa che è un evento che viene passato da una parte all'altra questo evento può essere trasformato prima che arrivi nel modello quindi nello state management nella maniera che il team ha deciso di avere basato sulle sue funzionalità quindi a livello di design si diventa estremamente semplice utilizzare un evento piuttosto che avere una cosa condivisa soprattutto su una parte chiave come modello che può divergere in diversi modi quindi questo secondo me è il modo in cui si va a comunicare tra Mike e Fontana.

Voglio per analogia provare a fare una proiezione pensando al CQRSS quindi a quella modalità semplificando di gestione del dominio e dei comportamenti più che del dominio è una parte che possiamo inquadrare a livello architettura dove già abbiamo un pub sub da una parte e poi qualunque cosa vogliamo fare o dobbiamo mandare un comando per dire voglio fare questo oppure andiamo a fare una query ecco se noi immaginiamo il nostro sistema come un sistema il nostro sistema di comunicazione come un sistema pub sub però non stiamo coprendo l'azione della query di per sé cioè voglio andarmi a prendere la configurazione che condivisa tra tutti i micro front end in quel caso come qual è la strategia per attingere a quel pezzo di informazione condivisa non so se sono riuscito a spiegarmi perché mentalmente stavo facendo un'analogia con quell'approccio quindi.

No no è chiaro quando ci sono dati condivisi dove il grande classico può essere per esempio il token session token che può essere in un cookie o da qualche altra parte che viene utilizzato da tutti i micro front end per chiamare il back end e quindi consumare api in quel caso lì si va nelle parti comuni e standardizzate quindi di solito un cookie o un local storage se vogliamo andare a livello di security molto alta ma avendo un impatto sul user experience si può pensare anche un web worker tenendolo in memoria quindi ci sono modalità per poter condividere queste cose e per convenzione vai a sostanzialmente a dire a tutti gli sviluppatori guardate il token JWT token per esempio è come cookie quindi tutti andranno a prenderselo come cookie puoi creare dei layer per astrarre alcune combinazioni quindi tu potresti creare una libreria nella contenitore dei micro front end che dice o anche una libreria che va a implementare in ogni micro front end che ti dice sostanzialmente guarda tu hai la possibilità solo di recuperare queste recuperare il token non puoi scriverlo e quindi puoi andare a crearti questo tipo di logiche utilizzando metaprogramming in javascript puoi utilizzare una libreria che ti vai a creare tu questo deciso da qua dal livello di sicurezza che vuoi prendere che vuoi mettere in piedi però in generale questa è un esempio nel caso della configurazione iniziale di solito la configurazione avviene in una fase ben precisa del processo dove per esempio io voglio avere la configurazione per capire che ne so che nazione l'utente è voglio capire una serie informazioni che permette alla mia applicazione globale di avere certi tipi di comportamenti e in quel caso lì di solito è iniziale e può essere fatta dal contenitore di tutti i micro front end e esposta in qualche modo può essere local storage global scope quello che decide l'azienda e poi viene utilizzato tutti i micro front end esempio pratico netflix qualche anno fa quello che faceva non ho controllato se lo fa ancora sostanzialmente quando vai a richiedere la pagina web lei va a iniettare prima di restituirtela un json che è statico all'interno dell'html che contiene tutti i tuoi dati quindi i tuoi dati sono in chiaro sulla tua pagina quindi qualsiasi per qualsiasi pezzo del javascript dell'interfaccia può andare a recuperare su quell'oggetto globale i dati dell'utente quindi se ti serve l'email se gli serve l'user id quello che è questo poi è uno dei possibili approcci che puoi avere però ripeto dopo dipende da azienda da azienda da azienda da processo a processo che qual è il quello che vuoi utilizzare però si capita che hai questa tipa di questo tipo di richieste dove vuoi centralizzare la richiesta non vuoi farla per ogni micro front end ed è perfettamente normale l'unica cosa appunto dobbiamo essere smart nel modo in cui andiamo a gestirlo e ci sono casistiche fuori che sono state fatte da me da molti ingegneri e appunto basta solo capire qualche quali sono i trade off che dobbiamo dobbiamo abbracciare per poterlo fare.

Si come dicevi mi viene in mente che possiamo avere una libreria condivisa utilizzata a tutti i micro front end oppure esporre un api nel host container che monta i vari micro front end perché penso che tu ne abbia parlato in qualche talk no il fatto che l'host spesso espone un api che ne so per l'accesso al basso livello del sistema alle web api e un po semplifica e mette a disposizione questo in realtà vedi dei trade off delle differenze tra i due approcci? Grossi, per esempio se pensiamo alla libreria per ogni micro front end viene abbastanza semplice da sviluppare il problema è mantenerla in sync quindi se nel momento in cui inizio ad avere una nuova versione, una nuova versione, una nuova versione la domanda che dobbiamo rispondere qual è la parte di governance che abbiamo messo in piedi per poter far sì che ogni micro front end ha l'ultima versione della libreria e questa è una sfida che appunto per quello ho enfatizzato molto che duplicare codice nel mondo distribuito non è così problematico come lo è in un monolita perché ci sono una serie di complessità che sostanzialmente invece di essere all'interno del codice adesso sono shiftate a livello di persone e di processi e spesso questi sono molto più complessi che la parte dei codici quindi avere della duplicazione su quelli su certi punti chiave perché chiaramente non tutto è fattibile design system classico esempio bisogna bisogna pensarci 36 volte prima di poterlo fare quindi se vai con le librerie hai questo problema qui senza contare che poi c'è un altro problema che spesso accade che il team responsabile per quella libreria se fa anche altre mille cose e c'è molteplici team che chiedono di funzionalità differenti il rischio è che a una certa il team che chiede di funzionare differenti e non vede la sua funzionalità nella libreria inizia a prendere iniziativa e invece di contribuire alla libreria centralizzata perché magari è chiusa solo per un team si crea la sua libreria che utilizza la libreria centralizzata e quello dopo è dove iniziano i casini perché dopo rimergiare diciamo le funzionalità della libreria centralizzata su una nuova inizia a essere molto complesso perciò tra i due preferisco avere la centralizzata all'interno dell'application shell dove però devi andare a fare contratt testing quindi devi essere sicuro che quella libreria centralizzata alla la stessa ipi contra tra i due credo che sia meno effort pensare a fare ipi contract testing piuttosto che fare che fare diciamo tutta la gestione di governance di cercare di non avere troppe cose centralizzate perché le ho viste entrambi e l'effort su uno è decentralizzato che è quello della delle piatta contrasti sull'altro è centralizzato in quanto hai un team che è responsabile per la libreria e se non hai la cultura di fare una sorta di inner sourcing dove tutti possono contribuire sulla libreria centralizzata con un team responsabile è complesso quanto lo capisco questa esperienza personale una cosa che volevo enfatizzare spesso e volentieri in queste discussioni quando parliamo di micro servizi sistemi distribuiti la problematica non è tecnica infatti ho avuto molta gente che nel mio libro hanno hanno descritto ma non è non è tecnico non fa vedere abbastanza codice perché quella è la parte semplice cioè quella è la parte che se sai scrivere una single page application se scrive un microphone tempo non è quello il problema ci sono solo dei piccoli dettagli a livello tecnico che è importante capire ma la realtà dei sistemi distribuiti è che spesso è più capire il trade off a livello globale quindi dalla parte organizzativa eccetera che gli sviluppatori non pensano ed è quello che spesso e volentieri cerco di enfatizzare e spesso parlo più di questo aspetto che della parte tecnica per rispiegare come fare una che ne so un ecdp request con axios tutti lo sanno fare quello che però è difficile pensare pensare in maniera olistica e guardare che impatto ha la mia decisione di utilizzare un approccio rispetto un altro è vero è vero io io ci tengo sempre a dire noi micro front e micro front end l'approccio lo usiamo a livello tecnico da decenni basti pensare alle server side includes o esi ma in realtà quello che mancava è la disciplina e l'approccio di governance poi vero tutto il resto viene da sé anche micro front end c'è un framework nuovo a settimana io questa settimana sto provando a capire quale può essere il ruolo per esempio di astro l'approccio di astro il nuovo framework in quest'ottica che è comunque interessante no e il ruolo del server side rendering in un contesto di micro front end che è altrettanto interessante il ruolo delle serverless function anche questa con doppia capriola per fare il collegamento però in effetti oggi stiamo facendo server side rendering delle nostre applicazioni per un bel pezzo d'applicazione e lo facciamo spesso e abbiamo questa nuova tecnologia che sono le serverless function on the edge che in realtà ci danno una mano in quell'ottica quali sono le potenzialità le altre potenzialità del mondo serverless nel contesto di micro front end? Ma ti dico serverless secondo me è il paradigma che più si avvicina a uno sviluppatore front end che vuole approcciare il server side rendering perché rimuove un sacco di complessità a livello di capire il networking sicurezza che ne so gestione del cluster e tutti quei topic che spesso erano delegati ma sono ancora in certi contesti delegati a diciamo chi effettivamente va a sviluppare la parte infrastrutturale.

Con serverless questa cosa è gestita dal cloud provider nel nostro caso AWS e ci permette di focalizzarci sulla parte di che vale di più che è il business value come lo chiamiamo di solito che sostanzialmente scrivere il codice che va a mappare diciamo l'interazione di business per l'utente quindi tutta la parte infrastruttura eccetera viene gestita diversamente perché viene gestito dal cloud provider.

Nel caso di server side rendering con micro front end ci sono diversi approcci per esempio Zack Jackson che è uscito da poco con il suo plugin per Mojo Federation con Next adesso sta lavorando a quello di Remix e quello di Node.

Quello che sostanzialmente fa è avere un contenitore che carica al volo tutti i vari pezzi che sono i vari moduli Node o nel caso di Next le varie pagine e poi le va a servire da una lambda verso il client quindi lui ha un unico codice che è questa lambda function che va a prendere tutti i vari remote che sono salvati in qualsiasi object storage o file system che sono disponibili su cloud, li va a comporre al volo e li va a servire.

Spesso e volentieri però chiaramente il fatto che c'è una gestione completa da parte del cloud provider deve anche farci riflettere quali sono le cose che dobbiamo imparare perché questa diciamo astrazione abbastanza chiave però ha dei trade off quindi il fatto di capire quali sono i limiti delle lambda come vanno a scalare vi dicendo basato sul nostro tipo di traffico è una delle prime cose che di solito chiedo quando vado a parlare con cliente quali sono i traffici che avete come avete il traffico a degli spike che vanno a incrementare da 0 a un milione di richieste al secondo come vanno e quale tecnologia avete utilizzato per le vostre lambda vi dicendo quindi ci sono delle cose su cui dobbiamo lavorare però diciamo che se penso a ricrearmi la stessa cosa con containers con virtual machine o in altri modi l'effort per uno sviluppatore per utilizzare lambda è molto piccolo quindi viene molto più delegata la parte di diciamo infrastrutturale sulla parte dello sviluppatore ci sono una serie di tool come AWSM che è il serverless application model che vi permettono di accelerare lo sviluppo dei vostri sistemi serverless che vanno in giro di secondi se siete già su cloud e hanno diciamo delle metodologie che permettono di sincronizzare il vostro codice sul vostro account in cloud account in maniera estremamente trasparente e semplice.

Chiaro insomma le possibilità oggi sono tantissime col serverless e a livello di complessità invece secondo te c'è ancora della strada da fare per semplificare in un'ottica di micro front end? Per esempio Astro che Astro anche se ragionavo sul micro front end a server static site generated e Astro da quel punto di vista portava un approccio interessante mi chiedevo ma il micro front end si può portare in un contesto di static site generation? Si può fare in modo frictionless? In un qualche modo però ho notato che quell'approccio alla Astro non so quanto possa essere inquadrato nel mondo del micro front end però comunque marcava una strada di astrazione della complessità tecnica.

Possiamo avere qualcosa del genere anche nel mondo serverless in un contesto di micro front end? Si ti dico Astro utilizza island architecture che è un concetto che viene dal creatore di Preact che ne parlava ancora qualche tre anni fa e con cui ci ho parlato e sostanzialmente loro hanno creato questo concetto di island architecture perché quello che volevano fare era sostanzialmente avere il server side rendering che è isolato quindi quello che chiamano progressive hydration o partial hydration che viene stato implementato e discusso online da Etsy per esempio che è un sito di e-commerce abbastanza famoso e lì l'unica cosa è che lo fanno solo sul lato server side rendering e quando ci parlavo gli ho detto ma quali sono le caratteristiche di un island architecture e mappavano in maniera molto similare a quelle di un micro front end perché c'è l'indipendenza.

Su static side generator credo che la complessità lì è capire a livello cioè se lavoro con un piccolo team non è un problema ma se lavoro su multi team e quindi alla fine la compilazione deve essere coordinata perché altrimenti rischi che vai a creare qualcosa che non vuoi può essere molto molto più complesso che avere tutto runtime perciò se è static side generator con divisione a pagine potenzialmente sei abbastanza in una botte di ferro.

L'unica cosa che bisogna essere bisogna diciamo spendere del tempo è a livello di automazione per essere sicuri che non vai a deployare una versione che è mezza fatta mezza no per un'altra parte dell'applicazione che non è.

C'è sempre il rischio che per un errore umano o di automazione tu ti ritrovi senza cioè deployando una cosa che non è che non è corretta online.

Sul mondo runtime invece ci sono dei boundaries più fissi dove effettivamente tu deploy la tua parte e quello che viene gestito dal resto dell'applicazione dovrebbe essere completamente indipendente da te quindi non è un tuo problema mentre sul static side generator secondo me funziona ma quando vai a decine di team che lavorano sulla stessa applicazione non sono molto diciamo confortevole a consigliarla.

Chiaro chiaro la mia era a sentimento sentivo insomma che c'era c'era qualcosa che condividevano sì vedo vedo l'orario di registrazione stiamo andando lunghissimi quindi io mi prendo giusto un secondo per ringraziare i donatori dell'episodio.

Questa settimana dobbiamo ringraziare due donatori che sono coloro che ci prendono in braccio e ci supportano nell'esperienza del nostro podcast il primo è Filippo Montani che ci dona tre birre scrivendoci un messaggio con scritto forza Genoa e io aggiungerei Belin e abbiamo anche Luca Francesca che anche lui ci dona tre birre quindi detto questo è arrivato il momento di sollevare i calici sono le 11 al mattino ma noi beviamo lo stesso sono le 10 da te Luca e facciamo un brindisi a Luca e a Filippo grazie grazie vedo che il tempo sta volando quindi io direi che passiamo direttamente al paese dei balocchi il paese dei balocchi il momento in cui i nostri ospiti i nostri guest condividono una lettura un talk un video che è stato interessante e che può essere utile insomma shareare alla nostra community quindi la mia domanda è Luca hai qualcosa da condividere con noi? Avrei un sacco di cose sono un avido lettore e mi piace un sacco informarmi di cose nuove una delle delle recenti letture che ho fatto che secondo me è fantastica anche basato su quello che abbiamo discusso durante questo episodio è un white paper che è stato scritto da Frederick Brooks negli anni 80 se non ricordo male o 70 quindi un bel un bel pezzo fa e parla appunto della diversità di accidental versus essential complexity e il titolo molto molto comune per per chi è nel mondo tech è no silver bullet e secondo me che è stato anche diciamo quando abbiamo quando diciamo no silver bullet è perché Frederick Brooks l'ha definito in questa maniera qua e lì durante il white paper c'è la definizione di perché non è un silver bullet della differenza tra complessità essenziale e accidentale e del link tra architettura e organizzazione che abbiamo parlato estensivamente durante questo episodio e secondo me è una lettura che sono mi pare un 20 30 pagine ed è stato un white paper bellissimo che ho letto di recente e che mi sento di consigliare a tutti.

E metteremo naturalmente nelle note dell'episodio Luca tu hai qualcosa per noi? Io sì un balocco anch'io con qualcosa da leggere tanto per cambiare un libro consigliatomi da un amico ciao Antonio è un collega e amico the software architect elevator di Gregor Hopp e si riprende anche un po quello che diceva Luca in questa puntata il problema il più delle volte non è tecnico ma è più è più ampio e questo libro appunto non l'ho ancora finito di leggere ma mi piace l'approccio soprattutto mi piace il problema che vuole risolvere è proprio quello di come gestire il grattacielo la nostra infrastruttura vista come un grattacielo dove ai piani alti c'è il management e nella zona macchine ci sono i sviluppatori in mezzo a tutti gli altri e il problema è proprio far capire a tutti il problema di tutti o quantomeno risolvere tutti i problemi che ci creiamo da soli sostanzialmente quando quando creiamo una un'infrastruttura di questo tipo.

Una frase ci cito una frase che mi piace dobbiamo evitare di trasformare di far sì che il sogno di un software architect sia l'incubo dei sviluppatori e non solo e questo è il problema che risolve mi piace l'approccio mi piace il problema e quindi lo consiglio a tutti.

Fantastico questo lo devo aggiungere alla lista delle cose da leggere insieme al white paper che ci ha appena condiviso Luca.

Anch'io ho un balocco ma questa volta non è un libro mi verrebbe da dire che ne so il libro rosso del ddd ma tipo l'ho portato 70 volte negli episodi di github quindi quello se non l'avete letto leggetelo.

Il mio balocco di oggi è una libreria qualcuno di voi sicuramente avete integrato delle mappe all'interno del vostro sito probabilmente avete utilizzato le mappe di google altrettanto probabilmente avete utilizzato leaflet con le mappe di open street map qualcuno di voi ha utilizzato mapbox benissimo mapbox è uscita qualche anno fa con una libreria che si chiama mapbox gl che utilizza le gl ma la cosa figa è che permette la realizzazione di mappe 3d attraverso dei modelli e l'estrusione praticamente delle montagne per capirci chi usa strava per mappare i percorsi di corsa in bicicletta e vede il percorso tra le montagne disegnato con camere che si muovono e di questo tipo ecco è possibile farlo con con mapbox 3d che è una figata pazzesca io mi sto divertendo un mondo quindi quindi provatelo bene eccoci qua luca allora è stato un super piacere di averti qua su github piacere totalmente ricambiata noi abbiamo dovamo registrare un'oretta in realtà siamo andati lunghissimi probabilmente ci odierai per questo tranquilli non è un problema mi ero mi ero già predefinito la giornata giù piccolo buffer dopo la cosa perché so che quando inizio a parlare non mi fermo mai non è decisamente colpa vostra allora sei in buona compagnia per noi è stato un super piacere averti di nuovo qui da noi e come ripetiamo sempre da oggi ma lo era anche dall'altra volta github è un po casa tua vienici a trovare quando vuoi noi nelle note dell'episodio metteremo il link anche al tuo libro quando ci siamo sentiti l'altra volta lo stavi finendo di scrivere quindi questa volta possiamo condividere anche il tuo libro non abbiamo parlato di scrittura tecnica e di scrittura di libri ma sappi che ti riromperemo le scatole guardate quando volete sai che è sempre un piacere venire in github quindi nessun problema il piacere è tutto nostro Luca grazie di nuovo a noi a nome della comunità immagino anche a nome di Luca no? Si, si ero in silenzio ma stavo stavo leggendo un po di cose e mi ha fatto un sacco piacere conoscere Luca e soprattutto ascoltarlo perché ovviamente prendo sempre appunti mentali ma anche fisici ogni volta e da oggi come come penso in ogni puntata da oggi saremo sviluppatori e persone migliori anche grazie a questa puntata di github questo lo dirò ad ogni puntata quindi molto molto emotional come finale.

No Luca grazie di nuovo per essere venuto grazie grazie di cuore e ricordiamo rapidamente che ti possono trovare su twitter mettiamo tutto nel link dell'episodio alla prossima settimana ciao ciao ciao ciao GitBar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con BrainRepo parliamo di linguaggi e tecniche di sviluppo web di metodologie ed strumenti immancabili nella cassetta di github.