Bene e benvenuti su github 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 va? fa freschino oddio è un tempo un po' pazzarello in questo periodo perché fa fresco poi caldo di nuovo poi di nuovo freddo, infatti c'è la felpa ma c'è il caldo, aprirò la finestra, vabbè insomma finiamo con questo small talk.Bando alle cianci vi ricordo rapidamente i nostri contatti e poi possiamo partire info@gitver.it per contattarci @brainrepo su twitter per contattarmi direttamente oppure il nostro fantastico gruppo telegram abbiamo superato, dovevi dirlo tu scusa Luca abbiamo superato sì dovevo dirlo io ma pazienza abbiamo superato i 1000 utenti siamo anche sopra al 1010, 1016 adesso non lo so perché c'è qualcuno che scrive e niente gruppo telegram di Gitbar podcast lo cercate su telegram e c'è il logo con il nostro buon Mauro e sotto la scritta Gitbar non potete sbagliare.E' bellissimo stare qua, erano quattro puntate che mancavo e niente, sono gasato.Sì e poi oggi siamo insolitamente 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 9 e un po' presto, ma io direi che è arrivato il momento di iniziare.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.Eccoci qua, eccoci qua.oggi è venuto a risalutarci un amico di Gitbar, 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 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 9 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 diciamo divulgare le potenzialità delle due delle due architetture poi se ci riesco bene sono contento dopo mi direte voi quanto bene si riesco a coinvolgere la community.Ci riuscirai tranquillo visto che sei un animale da palcoscenico e ti muovi facilmente sui palcoscenici di tutto il mondo.Io ricordo che tu insomma facevi tanti viaggi in giro per conferenze, eri superattivo e sei superattivo, "Ma come fai?" Questa è un'ottima domanda.Credo che il fatto che non, che secondo me è passione quella che ho più che altro, che più che lavoro, mi permette di andare oltre diciamo 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, ma anche ne so, 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?" e ti dico la ricetta, 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/a studiare in viaggio? Perché quando viaggi per conferenze, dei enormi slot di tempo sono dedicati a stai nella lounge dell'aeroporto o sei in aereo, qual è la tua ricetta, se li esci, qual è la tua ricetta per farlo? Guarda, io ti dico adoro andare agli aeroporti e adoro studiare e lavorare in aereo, infatti per il re-invent di quest'anno a Las Vegas dovevo preparare due talk, uno di questi l'ho preparato in aereo mentre viaggiavo per Madrid due settimane perché proprio non avendo distrazione, 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 arrivo 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, 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, che ne so, quelle due ore o tre 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, dopo che guardo il telefono dopo un'ora ho circa 120 notifiche di cose completamente inutili, dalle chat del calcio dei miei figli o della scuola o o amici, parenti eccetera eccetera, alle notifiche push dei cellulari che guarda Twitter, guarda che cosa ha twittato 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 microdistrazione 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.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 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 front-end Luca.Tu due anni fa sei venuto qua su Gitbar e ci ha introdotto l'argomento.Cosa è cambiato da due anni a questa parte nel mondo dei micro front-end? È cambiato tutto, no, tutto no, però è cambiato tanto, nel senso che due anni fa è stato, eravamo proprio agli albori, nel senso che sì c'erano delle aziende che l'avevano abbracciati 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.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 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 Microfront End.Ci sono aziende, tanto per nominarle alcune, come Netflix, come PayPal, come American Express, poi ci sono aziende più locali, tipo aziende grosse assicurazioni e banche sparse per il mondo che lo stanno abbracciando, cioè tutte quelle aziende che oggigiorno stanno utilizzando i microservizi, è probabile che abbiano bisogno anche di Microfrontend, 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, diciamo, l'adozione porta è quello che viene chiamato l'agilità per un'azienda di poter modificare parti dell'applicazione da API fino al front-end 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 Microfrontend 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 microfono, cioè esistono delle esigenze tecniche che ti dicono adotta Microfrontend o il driver è sempre gestionale e organizzativo? No, allora diciamo che ho parlato con molti sviluppatori e anche startup che vogliono abbracciare Microfront End.Il problema secondo me, che non ci rendiamo conto, è che spesso quello che la gente vede nei Microfront End, ma nello stesso per i microservizi, non è tanto l'architettura che gli interessa, ma sono i benefit che gli interessano.Quindi il 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, diciamo, 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 due anni fa, è che comunque c'è un uno sforzo addizionale nell'utilizzare queste architetture perché tutta la parte di come gestire i flussi di lavoro, come gestire le automazioni per il diciamo 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 andando, stiamo evolvendo parecchio sul mondo microfrontend, nel senso che prima dovevi farti molte più cose per i fatti tuoi, 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 di composizione con single SPA o con mojo 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 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 front-end 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 quelli che vengono chiamati artificial boundaries che sono sostanzialmente fisici quindi sostanzialmente io ho un file che è staccato da un altro quindi sicuramente non va a intaccare.Quindi da un lato andiamo a renderci, andiamo a spostare la complessità dal fare una complessità implementativa di design pattern, di scrittura di codice, a invece una strutturale, quindi la parte di automation, della parte di come andare a definire il deployment, come andare a implementare soluzioni come canary release, bluegreen deployment, nella parte di produzione.Quindi ci sono una serie di complessità che invece di essere applicate a 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 microphone tend non funzionano".Però in realtà non è che sono i microphone tend di per sé che non funzionano, è che non si è investito, perché giustamente una startup deve generare valore il prima possibile, si è investito sulle parti che invece sono quelle che rendono i micro front end una soluzione estremamente fruibile e quindi tutta la developer experience e la parte di automazione.Parlavi di start up no? E la cosa mi ha fatto ragionare.Intanto è vero quando si adottano micro servizi/micro front end 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 front-end monolitici perché magari sono accoppiati, perché mille problemi e ti viene questo mostro a sete teste che è difficile da domare.Hai parlato dell'ambiente start-up che è il posto dove questo tipo di condizioni si verificano più spesso voi perché c'è e c'era adesso un po' meno una hype gigante in questo settore no? "eh 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, diciamo, solo i Mac frontend che possono 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 che 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 Mac 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, aggiungeva 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, vabbè, 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 che devi, diciamo, cestinare.Quindi sostanzialmente c'hai 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ù semplice da gestire perché al momento non ti serve più e sei completamente nel nuovo mondo, beh, cancelli 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 un approccio rispetto che un altro.Sì, guarda, l'altro giorno parlavo al Lyon JS con un ragazzo che lavorare se non mi ricordo per una qualche banca o assicurazione qua, 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 plethora di framework ok? Quindi abbiamo Micro Frontend 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 Stealth Seal e abbiamo una roba tipo un rombo dove abbiamo l'accesso centrale e 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 l'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, 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 e Vue hai 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 bitigare un altro problema che c'è all'interno dell'organizzativo spesso, che è una questione di pigrizia sulla coordinazione dei team.Quindi essenzialmente loro dicono, spesso e volentieri, ho visto aziende che dicono "No, no, ma noi facciamo così, perché così tutti gli sviluppatori possono fare quello che vogliono".Il problema reale è che non è solo una questione tecnica che vai a impattare sull'utente, però è anche organizzativa, nel senso che se tu pensi ok, un'applicazione dove c'hai React, Angular e Vue nella stessa applicazione, tu stai portando visioni differenti che sono fatte dall'esterno all'interno dell'azienda.Quindi tu, differenti, quindi ti stai portando una community differente, via dicendo.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, gli 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.Ti dico, a me era successo ancora nel lontano 2016, quando ero 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.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 un view 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à.è vero, è vero.Vai Luca.No, sì, no, stavo pensando proprio all'analogia tra i microservices e i micro front end perché appunto nei microservices hai, è vero, più libertà di scegliere la tecnologia, però una tecnologia adatta a quello che devi fare, cioè 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, 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 microphone 10 no, perché come dicevi tu, tu puoi ritrovarti che ci sono state aziende 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 va aggiungere delle variabili nello scope globale eccetera e qualcun altro fa l'override e lì iniziano le complessità e dopo devi capire se non sei abbastanza esperto nel fatto di gestire la parte di observability propriamente per la parte di frontend rischi che diventa un casino e dopo il problema è "eh ma sono i frontend che fanno confusione".Secondo me spesso e volentieri c'è questa cosa che ci dimentichiamo e spesso sento il parallelismo microservizio e frontend sotto questo punto di vista qua però ci dimentichiamo che l'output è differente cioè uno esporta un API che spesso e volentieri è JSON e quindi va bene fin tanto che sono totalmente disaccoppiati vanno a comunicare in maniera standard quindi utilizzando JSON o quello che è, dall'altra parte invece dobbiamo avere un output che è standard ma il problema è che è "couple" perché vivono nello 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 del 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 che siamo così lontani anche su Microfrontend.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 microservizi adattarlo nel mondo front-end e riproporlo al front-end developer in una chiave che magari viene presa meglio.Però spesso e volentieri ci dimentichiamo che ci sono state centinaia se non migliaia di sviluppatori che hanno già passato le pene 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 cognitive load legato al nostro lavoro.Tu hai parlato di cognitive load legato al fatto di utilizzare più framework in un'approccia 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.Per un secondo.E anche più di un secondo, va bene.Beh in attesa che Mauro ritorni, mi permetto solo di dare un avviso visto che abbiamo citato un po' l'inclusione di framework, librerie diverse.Se dovete includere jQuery fatelo per riconoscenza e solo per riconoscenza, non ci sono altri motivi in questo caso.Non so se mi confermi.Oggigiorno direi che jQuery ha dato quello che doveva dare, ha spinto quello che doveva spingere e adesso grazie a Dio ci sono scensi di migliori.No, questa una storia che deriva da ormai a un annetto di tempo per il quale motivi di usare GQuery è sicuramente la riconoscenza per tutto quello che ha dato, magari ogni tanto includetelo e fate un query selector così fategli fare questo e basta.Sono tornato a dire che non risposta ai clienti.Ovviamente è uno scherzo ma...Vado via io e vi ritrovo a parlare di GQuery, aiuto che succede.vedo che parli ma non ti vediamo e non ti sentiamo.Pronto? Pronto? Vedo che stai imprecando adesso.È dal simbolo che vedi sulla parte della traccia audio.Ho riconosciuto il pattern dell'imprecato.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, Micro Front End è 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 micro front end 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 regole dell'inter o di pretier, piuttosto che come risolviamo questo tipo di problemi, usiamo una mappa o facciamo un cicloforo, adesso sto banalizzando, però questo tipo di approccio alla consistenza aiuta poi nell'esplorazione 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'.Allora, la consistenza dipende come vai a gestire la parte implementativa dei microphone 10.Per esempio, in the Zoom avevamo lasciato scegliere agli sviluppatori che tecnologie volevano utilizzare.Quindi gli 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 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 più inventativa e alla fine in maniera organica hanno deciso di andare con React e MobX.Io ti dico, io personalmente sono un grande fan di MobX, quindi mi è sempre piaciuto come come State Management e quindi hanno deciso quello e pian piano è stato preso da tutti i team che stavano arrivando quindi questo è stato il primo team che voleva fare Mike Frontend 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 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'altra, che quello succedeva più raramente, perché dopo diventavano esperti del dominio e quindi ci tenevano anche ad avere 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, anche lì noi avevamo scelto Node e Go come linguaggi e avevamo forzato la mano su questi due, principalmente ci serveva 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 coerenza a livello di base di codice, ma se è come io creassi molteplici applicazioni indipendenti e il codice non dista in maniera...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ù in una 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 view mi sono sentito un completo idiota dopo due anni che...no un anno...ma che cazzo sto dicendo? sette mesi che uso solo react e in realtà questo attrito è pesante posso posso confermare.abbiamo parlato di micro frontend però come si dividono i micro frontend? Io, il mio user journey, il percorso che deve fare il cliente per raggiungere la sua meta, come l'affetto 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 è sloganata abbastanza, non solo sul front end, 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.È 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 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 MacFrontend, dobbiamo iniziare a capire come vanno utilizzati, come vengono utilizzati gli utenti e capire anche quali sono le, diciamo, le parti che in domain-driven design vengono chiamate i sottodomini.Ogni sottodominio è 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, abbiamo le landing page che probabilmente avranno un certo tipo di traffico.A una certa però la gente dice, ah, ma non mi interessa quello che c'è a 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 già 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 Mac frontend in parti più piccole.Perché qual è il problema? perché quando noi andiamo già a monte a, cosa che vedo spesso, a copiare il concetto di Microfrontend 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 è essenzialmente 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 Microsoft Teams 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 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 micro front end, riflettere 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 questo vale per i microservizi e vale per il microphone.Quindi non c'è un modo per dirti "ah, questa è 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 metriche, delle linee guida tra cui appunto il fatto di partire più a ampio sprettro e poi pian piano andare a dividere se necessario.Perché nel momento in cui dopo inizi 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 deployare, allora probabilmente stiamo facendo qualcosa di sbagliato.Cioè il fatto in cui andiamo a disegnare l'applicazione è sicuramente il traffic, come viene gestita la parte di visualizzazione degli utenti, la parte organizzativa, e poi quello che vuole raggiungere il business.Queste tre cose mixate 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.il 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 a livello 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 al modello devono ritestare le cose, devono andare a gestirsi i two village case, come sono stati i cambiamenti, riflettere nella loro base di codice.Quindi tu vai a fare un coupling a livello di design del modello con le varie UI.Questo per me è abbastanza complesso e non deve essere, perché nel lungo termine questo lo si paga.Soprattutto quando si hanno il giro di sviluppatori che ad una certa lasciano l'azienda o si spostano in altri team e arrivano sviluppatori nuovi che non capiscono completamente il dominio e quindi vanno a rischiare.Quello che io di solito suggerisco è invece essere più indipendenti, anche perché design time coupling porta anche dipendenze esterne per il deployment.Quello che io suggerisco invece è avere uno state management per Microfront End, magari condividere la libreria che si utilizza quando si hanno molteplici Microfront Ends nello stessa vista, e a utilizzare invece un Pub/Sub pattern, che è Publish/Subscribe pattern, che siamo abbastanza familiari con l'Observer pattern, e via dicendo, nel mondo frontend.Si utilizzava quando io avevo 20 anni, e anche prima.E sostanzialmente 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 del producer, quindi di chi emette l'evento.E secondo me questo approccio qui, io l'ho visto in pratica su parecchi clienti, e ho visto quanto beneficio porta, soprattutto sul fatto che adesso il mio team, l'unica cosa che deve fare è mantenere una lista di eventi che il mio microphone tender riceve in input e riceve in output.Questo significa che la mia parte di documentazione è estremamente leggera, perché di solito un microphone 10 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 il modello, che può divergere in diversi modi.Quindi questo secondo me è il modo in cui si va a comunicare tra Mike e Fontaine.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 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 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 session token che può essere in un cookie o da qualche altra parte, che viene utilizzato da tutti i microphone tend 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 dire a tutti gli sviluppatori "Guardate, il token, il 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 nel contenitore dei micro-content che dice...o anche una libreria che vai a implementare in ogni Mac frontend, che ti dice sostanzialmente, "Guarda, tu hai la possibilità solo di recuperare il token, non puoi scriverlo." E quindi puoi andare a crearti questo tipo di logiche utilizzando metaprogramming in JavaScript o puoi utilizzare una libreria che ti vai a creare tu questo deciso dal livello di sicurezza che vuoi mettere in piedi.Però in generale, questo è 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 di informazioni che permetta 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 in microphone 10.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 pezzo del JavaScript dell'interfaccia può andare a recuperare su quell'oggetto globale i dati dell'utente.Quindi se gli serve l'email, se gli serve l'user ID, quello che è.Questo qui è uno dei possibili approcci che puoi avere, però ripeto, dopo dipende da azienda, cioè da azienda ad azienda o da processo a processo qual è quello che vuoi utilizzare.però si capita che hai questo tipo di richieste dove vuoi centralizzare la richiesta e non vuoi farla per ogni microphone 10 ed è perfettamente normale.L'unica cosa è che dobbiamo essere smart nel modo in cui andiamo a gestirlo e ci sono casistiche fuori che sono state fatte da me e da molti ingegneri e basta solo capire quali sono i trade off che dobbiamo abbracciare per poterlo fare.Sì, 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 al web API, un po' semplifica e mette a disposizione questo In realtà, vedi delle differenze tra i due approcci? Grossi.Per esempio, se pensiamo alla libreria per ogni microphone Tend, 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 certi punti chiave, perché chiaramente non tutto è fattibile, design system, classico esempio, 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 funzionalità differenti e non vede la sua funzionalità nella libreria inizi 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 quella dopo è dove iniziano i casini perché dopo rimergiare, diciamo, le funzionalità della libreria centralizzata su una nuova, inizia ad essere molto complesso.Perciò tra i due preferisco avere la centralizzata all'interno dell'application shell, dove però devi andare a fare contract testing.Quindi devi essere sicuro che quella libreria centralizzata ha la stessa API contract.Tra i due credo che sia meno effort pensare a fare API contract testing, piuttosto 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 dell'API control testing, 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.Dio quanto lo capisco questa, le esperienze personali.Però vedi Mauro, una cosa che volevo enfatizzare, spesso e volentieri in queste discussioni quando parliamo di microservizi e sistemi distribuiti la problematica non è tecnica.Infatti ho avuto molta gente che nel mio libro hanno descritto "ah ma 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 sai scrivere un microphone ten, 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 spiegare come fare una HTTP 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 a un altro.è vero è vero io ci tengo sempre a dire noi in Microfrontend 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 Microfrontend ha 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 nuovo framework in quest'ottica che è comunque interessante no? Il ruolo del server side rendering in un contesto di microfrontend 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 il contesto di Micro Frontend? Ma ti dico Serverless secondo me è il paradigma che più si avvicina a uno sviluppatore frontend che vuole approcciare il server side rendering perché rimuove un sacco di complessità a livello di capire il networking, sicurezza, 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 chiamo di solito, che è sostanzialmente scrivere il codice che che va a mappare, diciamo, l'interazione di business per l'utente.Quindi tutta la parte infrastruttura, eccetera, viene gestita diversamente, perché viene gestita da Cloud Provider.Nel caso di server-side rendering, con Mac 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 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 al secondo, quale tecnologia avete utilizzato per la vostra Lambda.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 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 delle metodologie che permettono di sincronizzare il vostro codice sul vostro account, il cloud account, in maniera estremamente trasparente e semplice.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'otica di micro front end? Per esempio, Astro che Astro, anche se ragionavo sul micro frontend a static site generated, Astro da quel punto di vista portava un approccio interessante, mi chiedevo ma il micro frontend 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? Ah sì, ti dico, Astro utilizza Island Architecture, che è un concetto che viene dal creatore di Preact, che ne parlava ancora qualche tre anni fa, con cui ci ho parlato, e sostanzialmente loro hanno creato questo concetto di Island Architecture perché quello che volevano fare era essenzialmente avere il server-side rendering 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 sul lato server-side rendering e quando ci parlavo gli ho detto "Ma quali sono le caratteristiche di un island architecture?" mappavano in maniera molto similare a quelle di un microphone tent, perché c'era l'indipendenza, vi diciamo.Su Tatticide 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 più complesso che avere tutto a runtime.Perciò se è Static Site Generator con divisione a pagina, 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 sai.Cioè c'è sempre il rischio che per un errore umano o di automazione, tu ti ritrova senza...cioè, deployando una cosa 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 site 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, sentiva insomma che c'era qualcosa che condividevano.Sì, esattamente.Vedo l'orario di registrazione, stiamo andando lunghissimi, quindi io mi prendo giusto un secondo per ringraziare i donatori dell'episodio.*musica* 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".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 e 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 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 pezzo fa, e parla appunto della diversità di accidental versus essential complexity.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 perché non è un single bullet, della differenza tra complessità essenziale e accidentale, del link tra architettura e organizzazione che abbiamo parlato estensivamente durante questo episodio, e secondo me è una lettura che 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 ho qualcosa da leggere, tanto per cambiare, un libro consigliato mi da un amico, ciao Antonio, è un collega e amico, "The Software Architect Elevator" di Gregor Hoppe, riprende anche un po' quello che diceva Luca in questa puntata, il problema il più delle volte non è tecnico ma è più è più ampio, 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, nella zona macchine ci sono i sviluppatori in mezzo 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 creiamo un'infrastruttura di questo tipo.Cito una frase che mi piace, dobbiamo evitare di far sì che il sogno di un software architect sia l'incubo dei sviluppatori e non solo.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 Gitbar, 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 OpenStreetMap 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 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 dobbiamo registrare un'oretta in realtà siamo andati lunghissimi probabilmente ci odierai per questo tranquille non è un problema mi ero già predefinito la giornata aggiungendo un piccolo buffer dopo la pausa perché so che quando inizio a parlare non mi fermo mai quindi 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 Gitbar è un po' casa tua quindi 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 Gitbar quindi nessun problema.Il piacere è tutto nostro Luca.Grazie di nuovo a noi a nome della community e immagino anche a nome di Luca no? Sì sì ero in silenzio ma stavo stavo leggendo un po di cose e mi ha fatto un sacco piacere conoscere Luca e e soprattutto ascoltarlo perché ovviamente prendo sempre appunti mentali ma anche fisici ogni volta e da oggi come penso in ogni puntata da oggi saremo sviluppatori e persone migliori anche grazie a questa puntata di Kinkaku.Questo lo dirò ad ogni puntata quindi...molto molto emotional come payoff finale.Luca grazie di nuovo per essere venuto, 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! GitHub! git bar depressed developer.ut.a una volta a settimana ci troviamo davanti a due birre e come re repo parliamo dimagi e tecniche di sviluppo word di metodologie e di strumenti immancabili quindi nella cassetta mi chiedo...
