Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua sul nostro bar degli sviluppatori.Ormai le vacanze di Natale ce le siamo lasciate alle porte e siamo pronti per registrare questo nuovissimo episodio che ahimè sarà uno degli episodi più difficili di Geekbar.Abbiamo un ospite, la difficoltà non viene dall'ospite ma viene da me, nel senso che ho mangiato credo il taco più pesante della storia e quindi adesso fare una puntata al microfono con questo taco che mi gira per lo stomaco può essere complesso ma detto questo so che vi interessa poco quello che ho mangiato vi prometto che cancellerò qualunque tipo di rumore possiate sentire ahimè l'ospite dovrà subirsi lì detto questo io direi che vi ricordo rapidamente la contatti e possiamo iniziare.Info@gitbar.it @brainrepo su twitter sono i modi canonici per contattarci anche quelli che ormai non usa più nessuno.A) perché la mail, è bella e palle scrivere le mail.B) perché tanto twitter sta fallendo e non mascommeno ci faremo la nostra istanza mastodon.No! Abbiamo telegram, abbiamo il gruppo telegram, siamo in tanti, siamo belli e belle, siamo freschi quindi se non l'avete ancora fatto iscrivetevi e troverete tante piccole sorprese.Detto questo, anche detto con uno stile che mi ricordo un po' vannamarchi, io direi che possiamo iniziare quindi sigla! 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 abbiamo un ospite del quale sono super super fiero.L'ho precettato ad Alicante e voi sapete dall'episodio con Michele Riva cosa è successo ad Alicante, è successo di tutto e non riusciamo a dare una forma.Era anche lui là con noi, è una delle figure di riferimento dentro Nirform, lo definirei uno dei decani di Nirform.Abbiamo con noi Davide Fiorello, staff engineer a Nirform.Ho detto bene Davide? Sì, salve a tutti, hai detto benissimo.Grazie Mauro intanto per la presentazione, ho visto che ha ricordato Alicante, ho di recente ascoltato la puntata e ho visto che ha colpito e lasciato nel cuore di molti tanti ricordi.Mi compiaccio molto di questa cosa.Comunque, a parte il meraviglioso evento che abbiamo tutti nel cuore, grazie per l'invito di nuovo e via.Vediamo se riesco a essere all'altezza della presentazione che mi hai fatto.Io su questo non ho dubbi, ormai è già da un po' paio d'anni che ci conosciamo e quindi insomma e poi vedo su cosa lavori e come lavori.Abbiamo avuto più di una volta modo di confrontarci e lo faremo anche oggi parlando di un argomento che incendia un po' gli animi, crea un po' di fazioni e parliamo infatti di GraphQL.Qualche anno fa abbiamo fatto una puntata speciale, era il primo compleanno di Gitbar, avevamo questo questo format, se ve lo siete persi andatevelo a recuperare perché è esilarante, lo chiamammo Git Fighter ed era un episodio dove io come host tiravo fuori due fazioni, che ne so, tirammo fuori Vim e VS Code e in modo del tutto randomico assegnavamo una fazione a uno sviluppatore che doveva difendere col sangue la posizione e abbiamo visto situazioni dove chi usava Vim doveva difendere Visual Studio Code o chi faceva API REST doveva difendere, chi amava l'API REST/RESTful doveva difendere GraphQL e là uscì una frase che mi fece particolarmente ridere che diceva così nel difendere GraphQL si diceva "rest in peace" per rest no è arrivato è arrivato il nuovo dis la nuova tecnologia disruptive.Davide io so che tu ultimamente hai lavorato pesantemente su GraphQL e so anche che hai lavorato su Mercurius che è una delle librerie JavaScript per fare GraphQL.Ricordo bene? Sì, ricordi molto bene.Ho lavorato parecchio su GraphQL di recente e fra una cosa e l'altra ci lavoro da tanti anni.Alternata con periodi sì, periodi no, periodi d'odio, periodi di grande amore, adesso sono in un periodo di grande amore fortunatamente, quindi mi sono fatto idee contrastanti, me le sono legate, me le sono sostenute, mi sono un po' tutte, avrei potuto fare una di quelle pintate di cui hai appena citato da solo perché veramente va un po' a periodi.Adesso diciamo che dopo tanti anni ho un po' di base per iniziare non è insegnabile, perché ogni volta scopro qualcosa di nuovo, però per iniziare veramente a capire quando sì, quando no, se ne vale la pena, se non ne vale la pena, quindi diciamo che un po' di base me la sono fatta, da questo punto di vista.Su quello ci arriviamo brevissimo, però la prima cosa dalla quale vorrei iniziare è e una considerazione.Allora, quando per la prima volta approcciamo una tecnologia, in questo caso è GraphQL, ma potrei dire la stessa cosa di Rust in quest'ultimo periodo, abbiamo un primo momento di spaesamento e se devo portare la mia esperienza, quando per la prima volta ho visto gli schemi di GraphQL, ho detto "ma che cazzo è sta roba?" Ed era uno dei primi momenti di GraphQL, dove la specifica sembrava una ricetta scritta in aramaico, si capiva ben poco, non c'erano tool belli che pronti o erano poco famosi tool come Apollo, che poi per un po' di tempo è stato uno dei market leader su questa tecnologia e cazzo mi sono sentito completamente spaesato, ho dovuto ritornarci più di una volta su GraphQL.La mia domanda è come è stato il tuo primo contatto, il tuo primo incontro con GraphQL? Allora la prendo un po' lunga, io sono, come hai detto tu, anni che lavoro per mia era forma prima prima di questa esperienza da comodo remote worker dall'ufficio di casa mia ho lavorato e ho vissuto due anni in Olanda e ho vissuto e sono andato in Olanda proprio nei due anni della grande rivoluzione del web moderno come lo conosciamo oggi.Arrivo là come sviluppatore angularjs lavoravo in KLM, l'airline, il mio tech lead, un pazzo scatenato, decide che dobbiamo usare questa nuovissima tecnologia che si chiamava React, che nessuno conosceva.Al che io gli dico "guarda, io sinceramente non ho idea di come funziona" e lui "neanch'io, però ci mettiamo lì, ce la studiamo e vediamo".Quindi in quell'occasione cosa scopriamo? scopriamo che Facebook, che fino alla settimana prima era l'azienda che ci faceva mettere i like alla persona con cui volevamo provarci, perché era uno dei grandi utilizzi di dieci anni fa di Facebook, adesso vai a una roba da...Penso che lo sia ancora, anche se tra i boomer.Esatto, adesso infatti io che sono un boomer, ormai non lo uso quasi neanche più, però all'epoca ero un intente molto forte di Facebook e quindi scopriamo insieme che Facebook fa della tecnologia, quindi ho iniziato un po' a seguirlo e quando dopo React, parlo dell'epoca in cui si usavano i mixins in React, adesso non so in quanti li abbiano mai visti.Usavamo Fluxor come state management, Redux non esisteva.Subito a ruota Facebook è uscito con la presentazione GraphQL, GraphQL che ho iniziato a usare subito, tant'è che probabilmente c'è ancora il mio nome da qualche parte, nella mia vita a Amsterdam ho aperto il primo meetup di GraphQL.I meetup ad Amsterdam, come tutte le città dove ci sono molte start up, sono molto vivi.Quindi apri con un paio di colleghi questa cosa, quindi il primo approccio è stato lì.Ed è stato un innamoramento totale, perché era figo, diciamo, di cose come stanno.poi soprattutto da persona che ne vedeva solo i pregi, non vedeva i difetti, non avevo in produzione una piattaforma con dei terabyte di dati, avevo semplicemente le mie applicazioni fatte e quelle usavo, quindi si andava di server quello buttato fuori da Facebook perché Apollo ancora non esisteva.All'epoca Apollo aveva Meteor e hanno avuto un'idea geniale nello switchare verso un GraphQL quando Meteor fondamentalmente era nato, aveva fatto l'esplosione ed era morto praticamente subito.Quindi ho avuto l'occasione di lavorarci subito e poi è rimasto una passione, non ho praticamente messo mai niente in produzione, finché dopo sono tornato in Italia, ho iniziato con Airform e la mia prima esperienza lavorativa, che l'ho fatta in Priceline, che è fondamentalmente il padrone di booking, quindi stesso tipo di piattaforma però sul mercato americano, mi hanno lasciato la libertà di scegliere e mi hanno preso nel momento in cui io volevo mettere GraphQL perché avevo bisogno di provarlo qualche parte.Ho fatto un po' questa follia da un cliente di queste dimensioni.Michio è coraggioso! Ah sì, io sono uno che ha la testa bassa.Io se sto sul progetto non ho paura a fare scelte.Se devo fare scelte per altri sono sempre molto più tranquillo, ma se sto sul progetto mi prendo proprio le mie responsabilità senza problemi.Quindi andiamo là, nel frattempo già uscito a pollo nel frattempo e quindi abbiamo messo in piedi la prima applicazione, ti parlo di sei anni fa ormai, la prima applicazione con un serverino non era particolarmente complesso ma l'interfaccia ci ha aiutato tantissimo.All'epoca la complessità era nel front-end, ultimamente tutto ormai è nominato Mercurius, i miei progetti recenti sono molto più sul...Poi su Mercurius ci andiamo perché ho avuto modo di sfagiolare un po' la codebase ancora prima di un refactoring recente che è stato fatto e io gli avevo fatto un po' di cosettine su Mercurius un po' di tempo fa, quindi poi ci andiamo e parliamo di Mercurius che è un progetto del quale andiamo molto proud a livello aziendale.Assolutamente sì.Per rispondere alla vera domanda che mi hai fatto, cioè come mi sono approcciato, tu hai detto che ti sentivi un po' spaisato.Io raramente mi sento spaisato nelle tecnologie, ma non perché sono un figo e le capisco subito, perché non capisco un cazzo fondamentalmente.Io vedo solo ed esclusivamente le parti buone e dopo una settimana che ci sono sopra esordisco con la frase che chi mi conosce benissimo sa che la dico ogni 3 persone..."La roba è una merda" No, che è in questo caso Graf QL, Graf QL per me non ha più segreti e allora quando dico questa frase vuol dire che in quel momento inizio a capire qualcosina e da lì i dubbi che non avevo perché fino a quel momento non ne avevo saltano tutti fuori e poi me l'ho avuto con tutto, abbiamo parlato in pre-meeting, abbiamo parlato di MongoDB, ma con MongoDB è stato lo stesso identico approccio per me.Poi dopo ho trovato i vari difetti che aveva, trovo comunque che sia un gran prodotto, ma all'epoca ci facevamo anche il caffè con MongoDB, quindi questo è un po' l'approccio, è il mio approccio alla tecnologia generalmente.A volte sono un po' più coraggioso e la mando in qualche produzione, a volte invece sono un po' più cauto e me la tengo per me, faccio un po' l'evangelistico alle persone che non la conoscono, elogiando senza avere poi fondamentalmente delle basi per elogiare.Adesso un pochino le ho, ma all'epoca decisamente non c'era.Sai Davide, hai aperto una cosa che secondo me potremmo per un attimo trattare come una parentesi ma anzi ti dirò mi hai dato un'idea per il prossimo episodio preparo proprio una musichetta che è la musichetta delle parentesi, the endless parentesi anche con un gingo.La domanda è tu hai detto talvolta io mi butto e in produzione magari ci tiro dentro una tecnologia innovativa, anche io io l'ho fatto, non l'ho fatto con la tecnologia, l'ho fatto con una metodologia, un pattern chiamiamolo così, con il functional DDD e tipo mi sono preso dei calci in culo pesanti che venivano da me, venivano dalla complessità che si è inserita nell'applicazione con l'inserimento questa roba e quindi mi dico talvolta siamo portati a spingere una tecnologia senza essere profondamente consapevoli di quella tecnologia.Che domande ti fai per non essere vittima di questo entusiasmo? Perché io me ne faccio alcune e sono curioso di vedere un po' come gestisci tu la cosa? Allora dipende molto dall'entità di quello che butto dentro, ok? Cioè provo a fare un passo indietro.Ti riporto il discorso GraphQL che ho buttato dentro il mio progetto di produzione.La valutazione è stata fatta considerando che non era un progetto ad alti performance, quindi io non lo sapevo quanto GraphQL fosse performante bene, sicuramente non era una roba che richiedeva dai performance perché avevamo un FF, era un servizio che chiamava delle pi di retro lentissimo perché immaginati tu vai a prendere dei dati molto complessi, noi facevamo i pacchetti, quindi tu dicevi dove doveva andare, lui automaticamente ti faceva aereo, albergo, automobili, quindi parlava con Amadeus che era un chiodo di AS400.Sì, non ho idea di cosa ci fosse dietro.È stato l'unico progetto, uno dei pochissimi progetti della mia vita in cui non ho usato un database.Perché? Semplicemente interrogavo i pi e questi mi davano dei risultati.Quindi la nostra scelta è stata fatta con la coscienza del "Proviamo, vediamo come va".E poi male che vada, io e il mio collega dell'epoca, anche lui di NearForm, che eravamo sul progetto, ci siamo guardati in faccia e abbiamo detto o se poi non va a tirare su delle rest API per gli altri giorni.Anche il servizietto era già pronto.Ma sì, non è che ci fosse chissà che.Più che altro il vantaggio di partire con GraphQL in quel caso è stato talmente forte che abbiamo deciso di giocarci la carta.Perché non fare delle API per un sistema così complesso? Perché ne avevamo una vagonata di dati, una marea.Erano quattro chiamate, ma con delle strutture enormi, quindi tanto vale che ci provi e andate bene, perché alla fine ci è tornato molto bene.Non avevamo mai usato Apollo sul front end e alla fine Apollo ha fatto il suo dovere, alla grande, è stata sicuramente una soluzione che ha pagato.In questo caso ero tranquillo, perché sapevo di stare qualche mese sul progetto.Io quando le prendo un po' alla leggera queste cose, quando so che poi ho il tempo di mettere delle pezze se ci sono dei problemi.E non ho paura a dire "ho fatto una cazzata" e non ho paura a dire "adesso scusate, datemi una settimana per rileviare a quello che è stato fatto".Alla stessa maniera, come raccontavo all'inizio, noi scegliamo React per fare questo progetto in KLM, quando tutta l'azienda usava Angular.Quindi noi proprio, "Vale, Spavaldi!" Ed è stata una scelta giusta, perché alla fine abbiamo visto dove era giusto.C'è forse anche da dire questo, nel senso che con un po' di esperienza ce l'abbiamo e sappiamo quando una cosa può funzionare o quando non può funzionare.a puzza di merda la sentiamo da lontano, o almeno abbiamo la presunzione di sentirla da lontano.E proprio in funzione di questo ti chiedo, dalla tua esperienza, quando ha veramente senso usare GraphQL e quando invece il tutto è un po' spinto dalla moda, dalla moda, no? Dal trend.Allora, ormai direi che trend non è più trend, perché ormai è una tecnologia stabile e funzionante e che tante aziende richiedono.Una cosa che sicuramente mette un punto a favore di GraphQL è la tipologia di applicazioni che uno va a fare.Noi lavoriamo Lo dice anche nella sigletta, siamo dei full stack developer che lavorano nel mondo del web, perché noi non siamo più dei full stack developer che fanno delle desktop application, noi lavoriamo in un mondo in cui in barba, questa ricito una cosa che abbiamo discusso di recente in un altro call in inglese che citavano prima, in barba ai tutti i progetti, cosa la si fa così tempo perso fare dei grafici e a decidere come fare il database, il software web moderno lo decide il designer che sia un produttore.Punto, cioè non giriamoci attorno, c'è un produttore, parlo ovviamente di una situazione semplice, poi quando si parla di grandissime applicazioni ci sarà un più produttore, più designer e cose diverse, però un'applicazione che uno commissiona e che uno decide di fare, che fa una certa cosa, ha un designer e una serie di designer che fanno le cose e un prodotto owner che li guida, che ha in mente una feature e semplicemente loro mettono una feature.Partendo dai design si fa il resto, perché così alla fine si fanno, almeno nelle mie esperienze, penso Si fanno le cose.Io penso di aver avuto la fortuna, lavorando in Myrford, di aver avuto la fortuna di lavorare in tanti progetti molto interessanti, clienti, clienti e clienti interessanti e questo è stato un sistema sempre.Ovvio che devi avere un'idea di quello che c'è sotto, devi sapere più o meno dove si andrà, di come gestire i dati, certo, ma alla fine il fatto che a un certo punto appare una label con un valore, dal giorno alla notte ti arriva.Quindi GraphQL da questo punto di vista è fenomenale, perché tu soprattutto in fase di prima creazione, sul mantenimento potrei parlare male di GraphQL però...No ma poi ci arriviamo perché mi sono appuntato un punto proprio su quello.Però sulla fase di progettazione, sulla fase di progettazione grafico è fenomenale.Con i tool che ci sono in giro, che velocemente da un database o da una struttura di atti, ti creano, parto dal platformatic di Matteo Collina, ma cito anche Asura, quindi sono due tipologie di tool che più o meno...Strapi? Strapi per esempio non lo conosco, che però più o meno, però sì, immagino che anche Strapi faccia la stessa cosa perché lui funziona comunque fornisce l'API, tu hai la possibilità veramente, in maniera veloce, di tirar su un servizio che va.E con le varie librerie che si attaccano a React rendono veramente velocissima la prototipazione.È una roba impressionante fare prototyping in GraphQL, è molto veloce.Perché tu non ti devi curare di niente, tu devi semplicemente buttare dentro dei dati, organizzarli, strutturarli, perché bisogna fare le cose per bene, non bisogna prendere una spadellata di attributi e buttarla dentro, cioè, c'hanno le cose per bene, però ti permette intanto di definire già, cioè il bello di GraphQL è che ti permette già di definire la struttura dati e quando l'hai definita sei a metà dell'opera, perché col sistema di resolver e tutte le cose che hanno, tutto funziona meravigliosamente, poi problematiche performance, avremo un'intera puntata per discutere queste cose, ma per partire da zero sicuramente che sia una piccola applicazione, che sia una grande applicazione, poi adesso con la federazione, con quello che ti permette di fare la federazione, è tanta roba.Si fanno grandi cose.Se mai la riprendiamo dopo perché questo apre un'avoragine.Quando io ho parlato con persone e mi dicono "ah ma GraphQL così", poi quando ci parli per bene, quando ti siedi con loro, quando gli fai vedere la semplicità con cui si fanno certe cose, l'affermazione da parte loro spesso è stata "ah, non avevo capito".Poi non sto dicendo che è la miglior tecnologia del mondo.Rest funziona da Dio e io le uso indipendentemente tutte e due, perché poi non sono sempre io a scegliere, a volte c'è chi dice "no, preferisco stare su quella", beh allora restiamo sulle tecnologie.Prima hai detto una cosa interessante sulla quale voglio costruire una piccola analogia.Tu hai detto le UI, comunque i prodotti, anzi mi correggo, i prodotti sono fatti dal produtt owner e dal UX, il designer.Io ho detto designer ma con designer intendevo tutto quel messiere via ruoli che fanno questo.Esatto e spesso questo non succede nei prodotti digitali, forse perché l'industria non è ancora abbastanza matura, forse perché abbiamo un po' un approccio cinofallico come diceva qualcuno, spesso perché i tempi sono quelli che...e spesso perché da sviluppatori abbiamo la presunzione di dover dettare una liga, no? Di dire "no, ma questo non si può fare".Posto che quello che mi disse il mio produtt owner è "la prossima volta che mi dici non si può fare ti prendo a calcine il culo", nel senso che tutto si può fare dipende sempre da budget, tempo e risorse, però al di là di quello un po' è quello che succede nel mondo, cioè nel senso che mio fratello è un architetto, il 90% del mio fratello è da fare i progetti, avere più o meno idea dei calcoli e della la parte strutturale, poi lo dà in mano a un ingegnere e gli dice, come vi faccio questi, prova a costruirvi questa immagine, prende un pezzo di carta, lo appallotto, lo dice voglio questa struttura del cazzo tuta strana, un po' esceriana, ok, lo dà a un ingegnere e gli dice bene fammela stare in piedi, ecco, dobbiamo un po' ricalibrare il nostro modo, dovremmo essere quelli che al "ecco fammela stare in piedi" dobbiamo saper dire "sì, te la faccio stare in piedi, questo è quello di cui ho bisogno per fartela stare in piedi.Non, non si può fare.Detto questo, aggiungo un'altra parte ricollegandomi al fatto dello schema che hai evidenziato.Sto per lanciare una bold opinion sul mondo JavaScript, quindi Davide, so che tu sei un amante di JavaScript, però secondo me la vera innovazione di GraphQL stata quella di dire "Ehi cari amanti di JavaScript, guardate che i tipi e la struttura dei dati che gira all'interno della vostra applicazione non è poco importante, è molto importante, probabilmente è centrale nell'applicazione".Quindi secondo me la cosa che ha portato GraphQL anche una certa disciplina sulla struttura dei dati in un mondo e in un'industria dove i dati venivano strutturati ad katsum perché bisognava release fast e break things.Cosa ne pensi in merito a questa affermazione? Hai detto che facciamo un'altra puntata JavaScript TypeScript mi sembra di aver capito.Invitiamo anche il nostro comune amico Matteo in quel caso.Ti ricordo una puntata dove Matteo disse che TypeScript era una proiezione mentale del tuo io digital, qualcosa del genere, cioè tipo TypeScript non esiste, sta solo sulla tua mente e dimenticalo! [Risate] Hai assolutamente ragione.Scherzi a parte, secondo me è stato un passo molto importante, poi un passo che generalmente gli sviluppatori un po' attenti già facevano prima, perché io quando lavoro con Fastify, non c'è un point che non abbia uno schema davanti, che mi fa la validazione, diciamo che la validazione e la sanitizzazione dei dati in input è un good practice che va fatta, appunto, senza tanto ne quanto sia in entrata che in uscita.L'aver messo nero su bianco il contratto è un passaggio molto importante, nell'unico punto da sviluppatore javascript in cui questa cosa è essenziale la comunicazione con l'esterno dove tu i dati non li controlli tu non sai che cosa ti entra e poi in realtà li puoi sanitizzare puoi validarli puoi fare un sacco di cose tra l'altro schema non è che grafico l permette di fare anche mille validazioni permette di fare tante cose su quelle diretti fondamentalmente fai tutto quello che fai anche sempre.Però è di base, così, naturale, ha una dipendenza molto basilare, che però fa, come dici tu, detta delle regole, detta delle regole che lo sviluppatore JavaScript, il cui motto spesso è "quick and dirty", più dirti che QuickTime ho delle robe nei miei software in giro che veramente fanno i miei ribrivi.La validazione, la stabilizzazione della struttura delle cose si fa con i test, però anche l'ePUB bisogna saperli fare, fare delle porcate anche con gli unit test è un'altra.E quindi questo è un po' l'approccio.Concordo pienamente, ha dato finalmente un linguaggio per comunicare correttamente fra front-end e back-end in maniera buona.Questo è essenziale.Facciamo una riflessione, magari mi sbaglio, però provavo a pensare al concetto di business logic.Non mi è chiara sta cosa nella mente, quindi te la dico come mi viene e poi ci ragioniamo insieme.Adesso buona parte delle nostre applicazioni sono, come dice Carmine, che a me oggi non sono il crudino della chiesa o il crudino dell'azione cattolica, cioè quattro end point che ti fanno il get, il post e fanno il crude fondamentalmente.Le nostre applicazioni sono piene di crudini, grazie a Dio esistono tool come platformatic, come azura che un po' ci risolvono il problema con i limiti che hanno, però comunque è una roba un po' da programmare un po' da Mechanical Turkey.D'altro canto però ci sono dei pezzi di business logic che invece hanno una certa complessità dove abbiamo certi dati che entrano, abbiamo delle dipendenze esterne che è un database e dei dati risultanti che non necessariamente fittano 100% il database.E' da un un po' che mi chiedo, in casi dove la business logic è fortemente presente, tu hai parlato di pachettizzazione, di booking, che sono dei casi dove in realtà il calcolo dell'availability di una certa struttura presuppone un'importante business logic.Ecco, GraphQL ci può venire d'aiuto? Te lo dico perché adesso sto scrivendo un motore di booking e mi sto ponendo proprio questa domanda mi sto chiedendo gli end point sono tre end point cagati ma GraphQL mi può aiutare in qualcosa dove la business logic è importante? Sì assolutamente non il linguaggio cioè non GraphQL inteso come linguaggio perché tu comunque lo interrovi sempre nella stessa maniera.Gli Gli engine, su cui il tutorial gira, con il sistema dei resolver, il sistema dei tipi che vengono forniti dal sistema, permette di fare delle cose molto interessanti.Poi c'è un po' di tooling da usare insieme per gestire le problematiche di loading, di caching, tutta una serie di cose.La cosa veramente figa di GraphQL, a questo punto di vista, è che tu, il singolo dato, puoi andare a mettere la logica nel singolo dato.Tutto ti viene tenuto in ordine dal sistema, cioè il sistema ti permette di dire che il prezzo del prodotto X è calcolato seguendo delle logiche.e tu puoi andare in quel punto a pensare esclusivamente a quel punto, non devi fare dei salti mortali, non devi andare a organizzare tutta una funzione di 50 righe perché devi ritornare a una struttura che poi verrà ritornata dalla resta.Tu ti preoccupi solo di quello.Ovviamente qualcuno potrebbe dire "eh, ma se tu devi andare a caricare dei dati lì, che poi ti servono anche dall'altra parte, con il resto li carichi una volta e li usi dappertutto.Questa cosa con GraphQL si fa nella stessa identica maniera, ci sono dei sistemi, tu hai modo, hai modo tramite i data loader di avere un unico punto d'accesso per il caricamento dei dati, questa cosa ti permette fra l'altro utilizzando anche il caching un po' di fregartene dell'andare a pescare un dato.Quante volte tu vai a pescare i dati oppure li metti nel codice perché non vuoi andare a richiederli tutte le volte con un sistema di caching ben fatto in realtà poi il sistema di caching non fa niente, non resta diciamo che GraphQL ti forza un po' a fare certi shape e questo non è un vantaggio perché alla fine è una forzatura però ti abitui un po' a lavorare con queste cose.Faccio un esempio, una tipologia prodotto, tu prendi il prodotto, il prodotto te lo restituisce solo lui di della tipologia e tu hai 20 tipologie in tutto, non ne hai di più.Parliamo di un caso abbastanza ristretto.Cosa fai, vai a chiedere la singola tipologia al sistema? Sì, gliela vai a chiedere, poi te la cachi, tanto la tipologia del prodotto è una roba che non cambia, quindi è una roba che può stare tranquillamente, puoi caricarlo ogni minuto, ogni minuto puoi fare di nuovo la richiesta.Quindi questa cosa, fai benissimo il resto, la fai dappertutto.Con GraphQL puoi tranquillamente nel tuo resolverino fare questa cosa fregandotene delle performance perché tanto un sistema di caching o di pre-loading o di cose fatto per bene ti dà tutta questa automazione e ti permette di farlo.Poi se devi fare invece una roba complessa perché devi fare dei calcoli e cose così, al fine è una funzione come un'altra e non è che ci siano delle cose delle cose speciali, cioè non ti facilita.Tu hai un ingresso e dei resolver, hai dei dati e ogni dato ha un resolver.Questo resolver ti ristituisce uno scalare se è uno scalare, ti ristituisce una struttura o qualcosa del genere se all'interno di questo attributo è un altro oggetto e così è cascata tu per fare le cose e avere dei risultati che la mia esperienza funziona.Poi se tu fai un node che restituisce un JSON statico è più veloce.Tieni presente che devi stare attento a cosa usi per serializzare il JSON.Questo è un problema non da poco.Ti apro una parentesi.In un progetto in passato avevamo un Postgres che aveva una colonna JSON, un record che aveva una colonna JSON.Il problema che una colonna JSON, quando è di 300K, 400K, è un JSON da 300K da deserializzare.Quindi un robo che noi prendevamo e così com'era, lo deserializzavamo e lo mandavamo al front end senza farci niente di quella deserializzazione, ci creava un sacco di problemi, perché quella la deserializzazione costava 50ms, che per uno non è un problema, ma quando tu questo json lo carichi, sono 50ms di processore, non sono 50ms di await.La deserializzazione Jameson e la serie di eduzioni bisogna sempre starci molto attenti.Noi ci andiamo molto rapidi là sopra, però in azienda ne abbiamo viste di due specie quando le performance contano e sono questi poi i casi in cui veramente si va a fare le pulci su tutto.Però voglio ritornare sulla complessità perché quello che hai detto è molto interessante, Cioè il fatto di concentrarmi nel caso in cui la business logic è importante sul micro dato all'interno di un albero di dati un po' più complesso è importantissimo perché ci permette, volendo, di ignorare il contesto.Il contesto, come dici tu, al quale possiamo risalire facilmente, che ne so, risalendo il nodo superiore o andando ad accedere a un context della situazione, però nel contempo io mi concentro su quell'elemento.E una delle rivoluzioni poi in realtà di GraphQL è stata quella di spostare parte di questa complessità di business anche sul frontend, perché il fatto di poter chiedere, quindi parte di questa business logic sul frontend, il fatto di poter per chiedere al database "Ehi gringo, a me servono questi dati" poi ci penso io "tu non ti preoccupare che ci penso io client side che non ti costa niente a te, vada bravo, dammi i dati come mi servono".Ecco, in questo approccio quali sono secondo te i vantaggi più grandi e quanto invece i calci nel culo che ne derivano da questo approccio? Parto dagli svantaggi e lo svantaggio l'hai detto tu nella frase "Dalli a me che a te non costa niente" che è la cosa peggiore in assoluto che uno possa pensare in un server GraphQL.Si tirano giù i server in questa maniera e non sto scherzando.E volevo portarti a parlare proprio di quello.Allora, torno al mitico talk presentato all'epoca da questa donna, non mi ricordo come si chiama, ma è uno degli altri ingegneri di Facebook dell'epoca, non so se lavori ancora per loro.Comunque, ricordo che presentava questa cosa meravigliosa in cui ognuno decideva che dati prendere e quindi tu in quella richiesta hai bisogno di nome cognome e numero di telefono, nell'altra richiesta bisogna anche dell'indirizzo quindi chiedi l'indirizzo e ti restituisce l'indirizzo.Questo sarebbe il modo perfetto indipendentemente da cosa costa andare a prendere questi dati che ne parliamo dopo.Nella pratica le cose non funzionano così.Nella pratica, ho visto abbastanza codice frontend per dirtelo.Funziona che io ho la mia entità prodotto, di questa entità prodotto mi faccio un bel fragment che mi restituisce tutti gli attributi del prodotto.Il fragment, per quelli che non lo sapessero, è diciamo una sorta di...è il modo che ha GraphQL per definire un'insieme di attributi e utilizzarli in vari punti in modo da non doverli riscrivere tutti.Possiamo dire un template per porzioni di query GraphQL giusto per semplificarlo.Esatto, c'è una cosa di questo tipo e quindi lo sviluppatore di turno una volta che si è fatto quel fragment fregandosene di tutto lo usa ovunque.e quindi hai un fragment che in un punto ha dieci campi di cui ne servono sei, nell'altro ha sempre dieci campi ma di cui ne servono cinque, e solo uno di questi è comune perché gli servono quegli altri.E questa è una roba comunissima, le codebase sono piene di casi di questo tipo, che il 50% delle volte non danno problemi, a parte il traffico, non sto neanche considerando il traffico, però il 50% delle volte non danno problemi.Però tu non lo sai, perché quello che è un nome/cognome/indirizzo e l'indirizzo dici "ma che cosa vuoi che costi?" tu non lo sai che cosa sta succedendo là dietro.Potrebbe essere che là dietro c'è qualcuno che per prendere questo indirizzo deve chiedere un servizio esterno, perché semmai ha un ID di questo indirizzo.Adesso l'indirizzo ho fatto un caso un po' che è raro, di solito sta dove sta il nome e il cognome, l'indirizzo.Vabbè, io ho visto i pi grafici che chiamavano Google per fare reverse geocoding di robe, quindi ho visto fatture di Google esplodere.Sì, perché poi quando dai il potere in mano in mano agli sviluppatori.Questi lo usano e spesso io...già la parola full stack che hai nella presentazione potrebbe scatenare giorni e giorni di discussione.Ma sta là per quello amico mio! Secondo qualcuno i full stack non esistono, secondo me è perché non ne avete mai visti i full stack, perché io di full stack ne visto tanti e ho lavorato con tanti full stack, che poi non vuol dire che sei un fenomeno ovunque, ma non sei un fenomeno neanche se sei un frontender, perché ci sarà sempre quella parte del frontend che conosci di meno e così vale anche per i full stack e vale per i backhand uguale.Io che ho avuto la fortuna negli anni di lavorare un po' a destra, un po' a sinistra, o a sopra e sotto, visto che parliamo di front e di back, quando io lavoro a front end faccio molta attenzione a che cosa vuol dire il dato dietro, non li vado mai a prendere con leggerezza questi dati.Purtroppo chi non ha esperienza dietro e poca esperienza in generale perché poi quando i front end di esperienza sanno benissimo il costo dei dati, anche se non si occupano loro di andarli a prendere, spesso dicono "ma sì, vado a prendere, poi ci penserò.E questi ha dei costi tremendi, serializzazione e serializzazione, richiesta di database.Se tu hai un DynamoDB dietro, che costa richiesta, è ovvio.Se tu fai poche richieste, è molto cheap.Ma se la tua query invece ne fa 5 e di qui ne hai 500.000 all'ora, iniziano ad essere dei soldi.Avere 5 o avere 10 fa la differenza e quindi ci sono delle attenzioni a cui bisogna stare attenti.Si sbaglia tutti, io per primo faccio del castronato in tante che sbatterà la testa contro il muro, però sul costo dei dati, il costo inteso come che cosa vuol dire andare a prendere, GraphQL, da questo punto di vista, non lo nasconde.Dandoti la possibilità di fare picking, ti dà spesso il diritto di prendere.Se tu chiami una REST API, non ti frega, tu chiami una REST API, sai già che i dati verranno ristituiti tutti.Questo è un altro dei grandi vantaggi di GraphQL, che spesso ci sono nelle REST API.Quante volte hai usato delle REST API che era il parametro full response o qualcosa.O complete.Allora usa GraphQL, cioè nel momento in cui devi dire che tipologia di dati vuoi dietro, usa uno strumento che è fatto per queste cose.Sì, assolutamente.Domanda invece, perché poi tra un po' voglio arrivare a un punto saliente, sul quale hai lavorato pesantemente e voglio trattare perché è una delle cose che di GraphQL si conosce poco, è male e invece secondo me ha senso approfondire.Però prima voglio farti una domanda.Apollo.Come vedi la posizione Apollo nell'ecosistema GraphQL? e soprattutto a questo punto in che modo Mercurius ribalta i giochi? Allora, partiamo da Apollo, partiamo dal fatto che è un po' che non uso Apollo, però leggendo un po' in giro e soprattutto essendo dalla parte di Mercurius, sicuramente c'è una differenza di performance.È un sistema più pesante per come è fatto, per come...non ne so le motivazioni esatte.Conosco molto bene Mercurius, so che è fatto da un maniaco delle performance, quindi da questo punto di vista funziona molto bene.Apollo è il leader del mercato, non giriamoci attorno, è nel mondo JavaScript e GraphQL lo fa in JavaScript, perché è fatto per essere fatto in JavaScript.Io se devo pensare di fare un GraphQL con un C# o con un Java, con tutto quello che comporta la tipizzazione, non è tanto la tipizzazione, perché TypeScript è tipizzato, però ti dà delle libertà TypeScript, che anche se è tipizzato, tu riesci a essere molto più veloce a fare core.C#, dico C# perché durante le vacanze di Natale, nelle mie due settimane di vacanze, ho lavorato in Unity a full time, sto facendo un giochino per i fatti miei, perché mi rilassa, e quindi ho dovuto lavorare molto in C#, che non conosco.Ci ho programmato all'inizio degli anni 2000, ma ovviamente adesso ho un altro linguaggio.Quindi queste complessità nel fare le cose più banali, nel caricare un JSON, capisci? Cioè, io il JSON lo carico e lo uso in JavaScript e in TypeScript.In C# devo fare un servizio di datore, c'è tutta una serie di robe che verrò fatte e poi verrò smentito da gente che C# lo conosce, perché io, se quei fatto, non lo conosco.Però, così a naso, mi viene da dire che GraphQL è nato per essere fatto da un punto di vista di comodità in JavaScript.Anche perché il 90% è consumato da JavaScript.Esatto, in Rust è sicuramente più performante.Però detto questo, mi sono perso due repriche, non mi ricordo più cosa stavo dicendo.No, la posizione di Apollo.Nel mondo JavaScript Apollo è dominante, è utile che ci geriamo attorno, se tu vai sui trend di download, di download si vede la differenza, sono due prodotti diversi a punto di vista dell'utilizzo.Poi Apollo è amato ovviamente da chi entra nel mondo node perché fai la ricerca e ti viene Apollo e il mondo nuovo.Anche perché è un prodotto commerciale supportato da...Tutta una serie di cose.Però, adesso butto l'acqua un po' al mio di mulino, anche se dovessimo usare un server a questo punto useremmo Express se ragionassimo con questo sistema.Poi la differenza è che Apollo ha un'azienda dietro a Express, per quanto sia proprietari dell'IBM fra una serie e tutta una serie, che l'hanno vinto a carta giocando, non mi ricordo qual è il motivo.Adesso Express dovrebbe essere sotto l'ala dell'IBM, non so proprietà, non proprietà, non so, però a certo punto mi sembra che fosse sotto un prodotto che l'IBM ha comprato, comunque dettagli.Però se noi dovessimo fare un server, useremo Express da questo punto di vista.Quindi invece Fastify, che se non conoscete la community di Fastify, adesso a parte Matteo, la conoscono.La conosco, la conosco.Esatto.Rompo le balle io.No, è un prodotto fenomenale dal punto di vista della community, è una cosa mostruosa.Mercurius non è attivo come fastify perché è più di nicchia in generale come prodotto perché grafico L è più di nicchia rispetto a un server rest poi per usare Apollo c'è fastify sotto e scusate Mercurius c'è fastify non è che non usate fastify se usate Mercurius però è un prodotto ben supportato fatto bene, fatto che funziona ha i suoi bug, ma ce li ha tutti.Però, una volta che si trova un bug, poi si va a correggere.Io l'ho usato in produzione in un progetto molto grosso, siamo contentissimi, il cliente è stato contentissimo.Un progetto complesso, che dà azione, con dieci nodi, non sto parlando di un serverino che serve tre entità, parliamo di una roba...abbiamo fatto una migrazione da Apollo a Mercurius e il passaggio...abbiamo tolto due cose, Sequel Eyes, che era una versione vecchia, e Mercurius.Sequel Eyes e Apollo.La rimozione di Sequel Eyes, che era una versione vecchia, che usava ancora Bluebird.Oh mio Dio! Esatto.Tappava non poco e il passaggio Mercurius che ci ha permesso di andarci un po' più spinti con il sistema di cash, con queste cose, ha fatto la differenza e il sistema era oggettivamente più veloce, ma molto più veloce.E quindi da questo punto di vista io voto Mercurius.Se si devono sentire più sicuri avere un'azienda supportata che vuole un servizio di pagamento di Apollo, molto danno, quindi lo si può fare.E' anche più supportata dal punto di vista del tooling di Apollo, c'è molte più cose.Il tooling fra l'altro è uno dei grandi problemi di GraphQL.Se vuoi dopo parliamo di che cosa vuol dire secondo me lavorare in GraphQL.No, io so su cos'hai lavorato e quindi voglio arrivarci su quello, perché tu hai ultimamente lavorato su Mercurius anche in progetti abbastanza grossi.È uno dei topic...hai lavorato anche su il core di Mercurius se non mi sbaglio.Io ho fatto refactoring, io ho estrapolato il Gateway e la federazione da Mercurius.Hai diviso il gemello Siamese.Ho diviso il gemello Siamese.Ha tirato fuori tutta la parte di Federation perché era strettamente accoppiata a Mercurio II.Sì, era un unico progetto.Adesso se vuoi usare la Federazione e vuoi costruire un Gateway, devi usare un modulo a parte.Il codice è quello, non è che l'ho riscritto.Soprattutto sulla Federazione, che bene o male, è quello.Sul Gateway l'ho estratto e ho dovuto fare un po' di ritocchi perché non era sufficiente ci sono andato un po' a fondo, ma è stato molto utile perché questo mi ha permesso di andare nel core.Dopo che l'ho fatto e che sapevo esattamente che cosa succedeva lì dentro, ho iniziato a prendere a mano un po' di issue aperte sulla federazione e a chiuderle, perché poi sapevo esattamente come andare a risolvere il problema.Dopo ho iniziato a chiudere un po' di tasche.A fare un po' di pulizia.Tra l'altro io ci ho lavorato per un progetto, ci tengo ancora a ricordarlo, era cercare di utilizzare Mercurius come gateway per diverse API, tra cui un API non federata di Strapi, andava probabilmente conosci quel ticket che è girato in azienda per un po' forse è il nostro amico Simone il quale mandiamo un grande abbraccio è stato l'ultimo a cui ci ha lavorato, cioè l'ultimo che ci ha lavorato è stata un po' una follia però di lì io per esempio ho approcciato al mondo della federazione GraphQL ce lo vuoi raccontare in breve? Allora io l'ho scoperto in questo ultimo progetto che ho fatto, molto grosso, non sapevo neanche se proprio si poteva fare perché io era poi un po' che non lavoravo con GraphQL, perché appunto lavorando nella consulenza e lavorando un anno, un anno e mezzo sui progetti, finisci su un progetto che non lo usa e tu semplicemente sei fuori completamente da quella tecnologia.Quindi per me era una novità quindi ho avuto occasione di rimetterci le mani e la federazione sì, l'avevo sentito parlare, ma non l'avevo mai fatta.Quindi, che cosa vuol dire fare la federazione? Vuol dire che tu, invece di dichiarare un unico schema, un server, tu hai ogni server, chiamiamolo service, visto che è il termine utilizzato, ogni service ha il suo schema, qualcuno di questi oggetti nello schema ha delle chiavi dichiarate esterne o delle entità che sono dichiarate come esterne e che lui si limita a sapere che esistono, nulla più, e a eventualmente fornire l'identificativo.E poi c'è un sistema di gateway che altro non fa che interrogare tutti tutti questi servizi che tu dichiari all'inizio e lui uno per uno prende questo schema, lo merge in un grande schema e fa vedere all'utente finale un'unica macchina che lo usa appunto come se fosse un'unica macchina.E questa cosa ti permette di fare grandi cose, ti permette di avere un bel...come si dice, un swarm, non mi viene la parola italiana, un stormo di nodi su Kubernetes per esempio in cui i due servizi che hanno bisogno di potenza hanno 24 o 36 nodi e il servizietto che non ha usato poca niente, ogni tanto, glielo mette solo uno senza dover necessariamente replicare uniche macchine con una serie di vantaggi mostruosa, perché di nuovo, quando si parla di progetti di un certo tipo, si parla di team.Non è che tu lavori su un prodotto, non è che se tu vai, cito Booking perché l'abbiamo citato prima, non è che Booking è un team dietro.Booking avrà 10 team, 15 team, 20 team che fanno cose.Io lavorava in KPLM, la home page di KPLM all'epoca ci saranno stati almeno 7 team che lavoravano per buttare fuori quei dati di quella home page, tra back end, front end, c'era un gruppo che faccia solo l'header, c'era tutta una serie di cose.Questa è la normalità, quindi nel back end avere la possibilità di ognuno lavorare sul proprio orticello fa una bella differenza e non è solo una questione di dimensione del progetto.Quando tu hai 10 team di tre persone, l'uno, quattro, stiamo sul piccolo, quando tu hai 3 per 10, 30 persone che lavorano sulla stessa codebase, puoi fare le merge, ci diverti.Cioè, sono tutta una servi lanciare i test di una codebase in cui lavorano dieci team, aspetti un'ora e mezza per finirne tutti.Quindi ci sono tutta una serie di vantaggi nello spezzettare e quindi la federazione ci dà quello che è fondamentalmente un sistema di microservizi su GraphQL.Merkulius la fa bene.È ai livelli di completezza di quello di Apollo? No, non lo è, perché l'hanno inventata quelli di Apollo.Mercurius non implementa la federazione, implementa la federazione V1 di Apollo.Quindi l'hanno inventata quelli di Apollo.finito le specifiche per capire come cazzo funzionava.Ed è vero che stavano nel sito di Apollo.E ci sono cose, per esempio, c'è qualcosina che non viene implementata.Serve? Io non ne ho avuto bisogno.Le due volte in cui avevo bisogno di fare una roba che non mi era implementata, ce l'ho girata attorno.Ce l'hai implementata? No, no, no.Ci ho girato attorno senza problemi.Ancora all'epoca non avevo questa conoscenza della codebase.della codebase per metterci le mani.Adesso probabilmente andrei a sistemare le cose, però per esempio Mercurius fa la federazione sulle subscription, che Apollo non faceva, adesso non so se nel frattempo l'hanno implementata, però tu puoi fare federazione sulle subscription usando Mercurius.Rapidamente, giusto per chi non lo sapesse, quando si parla di GraphQL si parla di query e mutation con le query accedi ai dati con le mutation istruisci il server GraphQL per fare delle azioni lo sto dicendo con la zappa però fondamentalmente questo fanno in più c'è un terzo elemento che è un query possiamo vederlo come una query che in qualche modo parla attraverso un altro protocollo possiamo immaginarlo come web socket e qui ti permette di rimanere in ascolto di qualcosa che poi ti arriva e non è strettamente legata a un processo di richiesta risposta.L'ho detto con la zappa, Davide, Abi.È un sistema di push che si usa con GraphQL, cioè tu ti metti in ascolto e lui ti manda i dati quando questi arrivano, quando vengono modificati.Esatto, è molto figo, devo dire che io l'ho utilizzato.Non mi è, in tutta sincerità, ben chiaro come farlo scalare però su quello potremmo aprirci un capitolo.Io non ho una grande esperienza su quelle perché al solito non so se hai un po' la teoria ma poi i progetti in cui l'hai usato non l'hai usato e quindi...Esatto non l'ho visto utilizzato in tanti progetti grossi in produzione però forse è un mio limite e quindi la mia domanda è sempre quella sì vabbè ma se scala come scala e quanto scala ma questo forse è un po' una nostra deformazione professionale.Prima di fare una cosa ci facciamo questo tipo di domande, però voglio arrivare a un'altra cosa abbiamo parlato di GraphQL, abbiamo parlato di REST, ma il nuovo arrivato nella stanza è di RCP quindi il nuovo protocollo RCP tipizzato per TypeScript per fare la chiamata remota di funzioni con i tipi scerati tra back end e front end.Non voglio affrontare il problema perché lo faremo in una prossima puntata, però una cosa che io ho sempre sentito a pelle dei protocolli RCP è che nascondono tutta la parte di operazioni sulla rete che nel meccanismo di comunicazione inseriscono della complessità, della complessità dettata dal fatto che qualunque tipo di comunicazione sulla rete non è solo "ti chiedo e mi rispondi", ma ci sono una serie di variabili che non controlliamo e che possono finire per darci dei problemi.GraphQL è un po' questo tipo di complessità, specie con la federazione, quindi dove ho un nodo GraphQL a cui chiedo che poi si occupa in modo quasi da reverse proxy, possiamo immaginarlo, di distribuire queste richieste per porzioni nei nodi che mi devono rispondere un po' astrae, nasconde tutta la complessità anche diretta che c'è tra i vari nodi E quindi alla fine la mia domanda è come possiamo osservare quello che succede in un ecosistema GraphQL federato, cioè come possiamo essere consapevoli delle merdate che da sistemisti possiamo aver fatto o dei lentezze dirette o dei problemi di questo tipo? Allora lì ci sono un po' di cose.Intanto bisogna avere dei DevOps coi controcassi, che è una cosa che spesso si sottovaluta ma quello del DevOps bravo è un ruolo essenziale e quando hai un DevOps bravo, tu tutte queste cose le sai perché c'è qualcuno che ti ha messo su un sistema come si deve.Poi sta nello sviluppatore andare a vedergli questi dati perché usando tool come Datadog, si chiama, Grafana, c'è soprattutto una serie di tool che fanno tante cose, ma sul sistema AWS stesso con Ray, come si chiama, qualcosa di Ray-Bridge.Non lo so, da un anno che uso Azure, quindi posso dire...Sono anche certificato AWS, il nome proprio non me lo ricordo.Vabbè, frega, ci sono più di 300 servizi AWS, c'è esatto, però veramente CloudWatch è un qualcosa che ti permette di vedere il giro che ha fatto la richiesta per i vari servizi, con Datadog, con Celsion, sono tutti una serie di servizi che ti danno le risposte, quindi con Datadog tu puoi andare a vedere, dato una richiesta, qual è l'acquiri MySQL, se il sistema ha fatto bene, che ti ha rallentato con la richiesta.Lo fa anche AppInsight.Esatto, sono alla base questa cosa, quindi le metriche, tutta una roba essenziale.Adesso sto lavorando, lo ricito, con Simone Sanfratello, che è molto bravo da questo punto di vista.Lui sull'andare a dire a questi sistemi che cosa sta succedendo dentro il codice è proprio una cosa che gli piace, si vede, gli vengono gli occhi quando ti racconta queste cose.Tanto sarà ospite prossimamentissimo, quindi lo sentirete tra pochissimo.Quindi lui è proprio bravo, queste cose, io per esempio sono più sull'architettura, su queste cose appunto un po' più ad alto livello, lui sul basso livello è un fenomeno.Quando hai, metti i dati come si deve, dopo tu recuperi tutte le informazioni che ti servono, quindi sai esattamente le cose come funzionano.Poi dove non ci arriva l'infrastruttura intesa come la VU, cioè l'infrastruttura, dove non ci arriva il tooling fatto da altri, ci si smazza e si inventano cose.finito il progetto dopo un anno in cui sono passato sul nuovo progetto, nei due mesi di pausa fa un progetto e l'altro, ho provato, anzi l'abbiamo fatto perché l'abbiamo costruito, ho provato a fare un po' di tooling proprio per Mercurius per andare incontro a queste cose.Quindi insieme ad altri ragazzi di Nier Form, noi in azienda abbiamo questa grande possibilità di fare un sacco di open source fra un progetto e l'altro.Abbiamo sviluppato questi due plugin, uno che è dato una federazione e ti racconta come è fatta, cosa che in Mercurius mancava, non so se c'è in Apollo, ma adesso abbiamo un sistema che dato una federazione ti dice il dato X in quale servizio è sviluppato.Sembra una scematta, ma per chi ci lavora è essenziale, soprattutto quando hai cinque team che lavorano ai nodi.Tu vedi una cosa "ma chi ha creato questo nodo? Aspetta che lo chiedo a Tizio" No, quella è una roba che tu se vedi solo lo schema finale non sai dove questa cosa viene fatta.Questa è la prima parte, la prima cosa che abbiamo fatto e l'altra, una cosa essenziale, è abbiamo fatto un plugin che crea il control, che ti restituisce le metriche della query che hai fatto.Quindi tu fai una query e gli dici esattamente che cosa è successo all'interno del sistema, che il resolver X ci ha messo 200 millisecondi ed è stato chiamato 5 volte e tu dici "come mai è stato chiamato 5 volte?" e vai a vedere e dici "hm, qualcosa non è andato" e allora vai un po' a sistemare e ti rendi conto che spesso i problemi sono nel codice di solito oppure vedi che appunto il resolver ci mette troppo tempo, viene chiamato troppo spesso e quindi sai che quel resolver deve andare a sistemare le cose Torniamo a quello che ti avevo detto inizialmente su GraphQL, il fatto che tu puoi concentrare su un singolo resolver è una grande cosa da questo punto di vista, perché riduce la complessità.Poi a volte risolvi con una bella cache, tutti i sanity ti aiutano, quindi Redis è un sidecar che deve essere sempre lì.Tra l'altro un saluto a Salvatore che ci sta ascoltando, io ricordo ancora una frase di Matteo Collina che disse "se io dovessi dire su cosa è basato il 90% della mia carriera in termini di performance, risponderei con una sola parola, Redis".Ha scritto anche un tweet su questo.Io l'ho sempre usato molto di parodai Redis, un po' come scelta imposta, come sistema di cache.L'ultimo anno, sempre per il discorso che la nostra esperienza ce la facciamo poi in base al progetto in cui lavoriamo, perché è lì che si fa la differenza.L'ultimo progetto di cui ho fatto questa redditorazione, di cui ho lavorato a stretto contatto con Matteo per un bel po'.Il progetto era gigante.Il progetto era gigante e a Redis ho imparato, grazie a Matteo che mi ha spinto un po' a fare certe cose, ho imparato a usarlo molto bene e non a usarlo nel senso che non posso usare Redis, ho imparato a sfruttarlo molto bene questa parte importante.Redis dovrebbe esserci non il progetto, un progetto che non ha un redis è un progetto che non ha bisogno di performance, e performance non intendo che deve restituire 20 millisecondi una pagina, però spesso e volentieri...c'è il fai dati, bom bom bom bom bom bom, è un po' di carico probabilmente.Esatto, avere un luogo in cui tu dici io non mi preoccupo di quanto ci mette a dare questo dato, perché tanto so che mi refresha ogni mezz'ora e io quindi posso permettermi ogni dieci minuti di andarlo a prendere da Redis e me ne frego, me ne frego di quanto costi il reale peso ed è una cosa che ti fa programmare con molta più leggerezza da questo punto di vista.Cashbill bisogna sempre invalidarla nelle problematiche, però non è sempre necessario invalidarla, perché spesso sono label, spesso sono cose, ci sono altri controlli successivamente che nel caso il valore non sia giusto ti risolvono il problema.Tanto c'è sempre un caso in cui per quanto ci mettiamo non potremo mangiare.L'utente carica la pagina, va a mangiare, torna e c'ha una pagina piena di dati che non funzionano più, perché nel frattempo sono cambiati e committa una forma di qualcosa che dietro nel frattempo è cambiato.Ma se hai usato le GraphQL Subscriptions o qualcosa, sotto il culo i dati, sotto il culo di San Cambiato.Lavorando nell'ambiente le scopri queste cose.L'idea di avere una scheda di un browser aperta per dei giorni non l'avevo neanche mai considerata, ma scopri che poi in realtà ci sono.E dici "ma come ha fatto questo a mandarmi dentro questi dati che è tre giorni, che non ci sono più?".Ma un utente interno dell'azienda, uno a cui abbiamo chiesto e lui ci ha detto "ah, quella pagina era riaperta una settimana" e io semplicemente a un certo punto ho deciso di dire "ok".Guarda, caso di stamattina, giusto per farsi una risata insieme, caso di stamattina io sto lavorando un sistema, non posso dire praticamente niente su quello di cui sto lavorando, però in breve, sto lavorando un sistema che ti dà, c'è una pagina prodotto, immaginate una pagina prodotto anche se non è un prodotto e tu devi fare tipo un booking su quel prodotto e Cribio ho iniziato a vedere tutti i 404, 404, 404, 404, non capivo perché ed era praticamente cosa era successo, una persona si era aperto 50 prodotti, ok 50, 100 tab, uno con ogni prodotto, questo che non erano prodotti, questi prodotti sono scaduti quindi non erano più presenti e lui ha praticamente lanciato non so se fosse uno scritto o qualcosa uno schedula call per tutti i prodotti e quindi io guardando le app in site ho detto ma questo è un coglione e invece no se tu pensi a livello di business io mi immagino sai ho avuto una un'azienda turistica per un po' di tempo e io mi ricordo la mia socia quando organizzava delle vacanze importanti, teneva anche per una o due settimane le pagine degli hotel aperti o le pagine dei servizi da bucare aperti.Bucare non credo si dicono.No, buchi, bu, bu, bu, e bucare.Renotare.E ormai abbiamo perso l'uso delle lingue.Esatto.No, però è una cosa più che verosimile e ormai l'abbiamo detto.Quindi comunque questi edge case ci sono e ci saranno sempre.Guarda, direi che potrei rimanere ore a parlare di questo, l'abbiamo anche già fatto.Faccio giusto l'ultima domanda sul topic perché è una domanda che mi sta molto a cuore.Qualche tempo fa ho lavorato su un API GraphQL, ero già in Irform ed era un grosso e-commerce, medio grosso e-commerce che faceva parecchi ordini al secondo e avevo un API GraphQL.E una delle cose più rompi balle in quest'API GraphQL era cercare di stabilire un contratto tra frontend e backend per la comunicazione dell'errore.GraphQL ha il suo modo di comunicare l'errore che ti dice error e poi c'hai del data non tipizzato.ok? E mi dico ma cazzo stiamo tipizzando tutto ok? Allora perché non tipizzare anche gli errori di dominio e dare un modo più agevole per la comunicazione di questi errori di dominio? sempre 200 ti risponde e già questo poco mi piace.Però come posso dirlo cioè ad oggi nell'API GraphQL vedo una forte distinzione tra gli errori di platform quindi legati al framework utilizzato, al server, agli errori di dominio.Secondo te hai mai vissuto questo tipo di problema.Te lo dico perché noi abbiamo dovuto fare un wrapper, abbiamo dovuto hackare il sistema degli errori di Apollo per fargli rispondere degli errori in grazia di Dio dove potevi querare GraphQL anche dentro l'errore.Sì, il problema non è tanto la struttura dell'errore.Il problema è che se c'è un errore quel dato ti torna nulla.Questo è uno dei grandi problemi.E l'errore non è lì, ce l'hai separato, ce l'hai da un'altra E quindi è un problema, perché se anche tu lo restituissi lì, col fatto che non hai messo nello schema di darti indietro l'errore, lui non te lo dà indietro l'errore su quel punto.Perché l'unica cosa sarebbe probabilmente quella di "non so neanche se si possa fare", a dir il vero.Però sì, hai ragione, non c'è una soluzione, che io sappia, non c'è una soluzione comoda.Ti dico come avevamo fatto noi, avevamo messo tutto dentro un bel try e catch, avevamo tipizzato tutti gli errori, li avevamo messi nello schema e quindi c'era il return 200, il return positivo, però di un tipo errore che poi ti dovevi andare lato front end e così abbiamo risolto.Lo mettevate nella struttura? Sì.Gli errori di dominio erano tipizzati? Sì.Ti faccio una domanda, tu chiedi una lista di 10 prodotti, il prodotto 3, il terzo prodotto della lista ti è dato un errore e quindi è nullo, perché si è rotto e quindi non ti è dato un errore.Tu hai una lista di oggetti che possono essere un prodotto o un errore.Ah, avete fatto un bel hack per fare una roba di questo tipo.Sì, era una taffazzata, però capisci che...guarda, io ragiono col concetto di Result, dove c'hai un left side che è il dato, un right side che è l'errore.E anche in JavaScript lo uso spesso, no? Una classe stupida con queste due proprietà e poi io faccio un, nel caso di Rust faccio un match o faccio una if in JavaScript in modo da validare questi due casi, in modo che anche l'errore diventa parte del dominio, specie in contesti dove il dominio è importante.Certo, sul crude della chiesa non lo farei manco morto, però mi immagino un sistema debugging e ti dice, immagina che stai facendo un pacchetto, no? E ti dice il servizio non è raggiungibile.Ecco, quello cos'è? Un errore di piattaforma o un errore di dominio nel caso del pacchetto? Se è un errore di dominio io devo poterlo trattare come oggetto di dominio, quindi devo anche poter cuerare, bruttissima parola, dentro quell'errore.una cosa che ho visto dei tool GraphQL è quella.Secondo me c'è un po' di lavoro a livello proprio di specifica da fare.Allora, faccio un piccolo passo indietro.Da questo punto di vista la community.Diciamo che le specifiche vanno molto a rilento su GraphQL, c'è una grande pressione di e farlo evolvere questo sistema.Alla fine ci sono cose nuove, poi ho portato delle grandi cose, le subscription inizialmente erano un'idea, non esistevano, poi lentamente le erano definite e buttate dentro.Non è velocissimo come sistema, quindi come specifiche.Quindi fare la roba che richiedi implica che tu la devi mettere in una specifiche, cioè il fatto che se un'entità non viene restituita tu potresti avere l'errore sul peso.Questa è appesante come affermazione.E bisogna pensarla bene.E me la devi restituire indipendentemente dal fatto che io te l'abbia chiesta o non te l'abbia chiesta.Perché è quello il problema.Perché se tu ci pensi, dovrebbe essere abbastanza semplice, tu per ogni entità restituisci eventualmente l'errore, nel caso sia un errore, ti mostro l'errore, se lo fai, vuoi fare un hacking, lo fai, il problema è che se tu non lo richiedi, l'errore non ti va indietro.Invece, lo metto tu, ti da una strutturina separata con un elenco degli errori, in cui ti dice se c'è stato un errore X in questo punto, cioè ti dice proprio se c'è stato un errore X in questo punto, quindi tu devi anche andarti a costruire dove c'è stato questo errore, che il 90% delle volte te ne freghi e dici "c'è stato un errore e non mostro i dati".Però se sei effeverato ti puoi anche sparare in bocca.Quello è un altro problema.Però bene o male gli errori vengono riportati.Davide non ti sento più, è successo qualcosa Non ti sento si è sparito completamente Allora datemi giusto un secondo prima di Andare in chiusura perché abbiamo un momentino che non possiamo [Musica] è il momento di ringraziare i donatori della settimana, le persone che ci prendono sulle spalle e ci accompagnano facendo in modo che ogni settimana possiamo portare del contenuto fresco abbiamo questa settimana alcuni donatori, questo perché sono un po' di più del solito perché ci siamo fermati qualche settimana per Natale il primo è Giovanni Italiano che ha replicato una donazione facendo una donazione di 5 birre con un messaggio.Auguri di buone feste e grazie per il podcast.Grazie a te Giovanni, abbiamo anche Leonardo Sabato o Sabato, io sbaglio tutti gli accenti, li metto in modo randomico, abbi pazienza di me Leonardo.Grazie per tutto il tempo che togliete a voi per dedicarlo al podcast e soprattutto grazie per la condivisione.bravi tutti, grazie a te perché fai in modo che noi possiamo veramente arrivare alle vostre orecchie ogni settimana ma abbiamo un altro donatore, Trebirre Andrea Quintino che insieme appunto a Leonardo e a Giovanni hanno fatto in modo che noi questa settimana abbiamo potuto pubblicare l'episodio Dicevamo, nel frattempo è esploso tutto, però parlavamo appunto della gestione degli errori.Secondo me comunque è uno di quegli ambiti dove si può aprire una bella discussione.Sì, sì, assolutamente, assolutamente sì.Cioè è uno di quegli ambiti in cui andrebbero affrontati un po' presi per le corne, trovare una soluzione comune per tutti, perché poi una volta che hai la soluzione comune, anche il tooling, dopo ce l'hai che ti funziona out of the box senza dover di nuovo reinventare la ruota tutte le volte perché poi la problematica lì.Cioè che poi detto tra mette secondo me la soluzione è anche abbastanza semplice cioè restituisci un tipo che può essere i dati o l'errore ok puoi definire l'errore se tu non lo definisci all'interno del nodo no di GraphQL se tu non lo definisci in caso d'errore hai o un errore generico o null e alla fine così lo risolvi però diciamo che posticipiamo questa discussione magari in uno dei nostri working group su GraphQL abbiamo trovato il topic per il prossimo working group io guardavo l'orologio siamo avvantissimo con l'orario non abbiamo dei nuovi donatori ahimè però insomma vi ricordo che insomma abbiamo la parte nel sito di supportaci se vi va buttateci un occhio e se vi va di supportarci fatelo pure e arriviamo dritti dritti dritti al momento tipico e topico del nostro podcast il momento il paese dei balocchi "E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Ed è questo il momento nel quale io chiedo a Davide se ha qualcosa da condividere con noi.Allora, ci ho pensato un po' perché sono andato un po' a guardarmi le vecchie puntate e ho scoperto all'ultimo di questa cosa quindi me la sono dovuta un po' improvvisare ma c'ho il regalo giusto.C'ho il regalo giusto che un libro che secondo me ogni sviluppatore e ogni persona che lavora nel nostro campo dovrebbe aver letto o quantomeno aver sentito illuminare, sperando che non l'abbia già regalato qualcuno prima di me, che è Quality Land.No, è la prima volta che lo sento.Potrei dire un tipo la guida intergalattica, ma non c'entra assolutamente nulla e non è neanche di quella brillantezza.Però, aspetta che lo cerco per bene, Quality Land di Mark Kling, che esiste in due versioni, per ottimisti e per pessimisti, il libro è lo stesso, non cambia molto, cambiano gli intermedi che ci sono fra un capitale e l'altro, che in quello per ottimisti sono più ottimisti, quello per pessimisti sono più pessimistici, che racconta il mondo che stiamo vivendo, il mondo dei social, il mondo dei sistemi di ricerca, il mondo della delivery, portato all'estremo, all'estremo dove si può arrivare.Faccio un esempio, non fai neanche più le ricerche sull'Amazon di turno, che non si chiama Amazon in loro servizio, perché loro sanno già che cosa spedirti a casa, perché ti conoscono talmente bene che lui viene lasciato, porto un esempio, dalla ragazza e dopo tre minuti gli suona il campanello con uno che gli consegna sei birre.Ed è molto divertente, è un librino non troppo impegnativo, che veramente divorato su un mondo distopico, distopico però divertente, che tipicamente il mondo distopico è un mondo triste, invece questo è un mondo molto allegro, molto divertente, quindi consiglio a tutti la lettura e per noi del settore ci sono sorrisi in più perché è un mondo che conosciamo anche da dietro, non solo da davanti.Esatto, no questo me lo recupero, è super interessante soprattutto ero alla ricerca di una lettura leggera.Io invece ahimè butto al cesso tutta la leggerezza che ci ha portato Davide per invece condividere con voi una roba molto figa.Voi sapete vi ho già rotto le balle su questo che sto provando con mediocre successo devo dire a studiare Rust per uno sviluppatore che viene dal mondo javascript e prima ancora dal mondo php probabilmente tipo Rust è l'uomo nero dei racconti da bambino, cioè una roba che ti spaventa a morte e siccome la paura non è mai troppa, ho beccato questa fonte, questa risorsa che è molto figa.Allora, sto studiando Rust perché voglio avvicinarmi alla system programming però nel contempo io ho ho fatto alcune parti dell'università un po' alla cazzo di cane, specie la parte di algoritmi, nel senso l'esame di APAL ho passato ma se mi chiedete come, non lo so, non ne ho minimamente idea.Quindi ha senso per me riprendere in mano gli algoritmi e siccome sto studiando Rust, come vi dicevo, ho beccato questo repository che è una figata pazzesca si chiama The Algorithms esistono delle versioni in linguaggi diversi ma la versione che vi voglio raccontare oggi è la versione degli algoritmi sviluppati in Rust e ci sono gli algoritmi di ordinamento, quelli sui grafi, gli algoritmi di dynamic programming, ci sono le data structure, ci sono gli algoritmi di ricerca, cifers, ce è veramente un gozziliardo, se avete bisogno di una lettura un pochino più pesante, ecco, qua probabilmente avete il repositori che fa per voi.Io comunque consiglio sempre il libro di Davide che mi sembra molto più interessante del mio balocco o almeno molto più divertente, però insomma, volevo condividere con voi...Anche lì dipende comunque.Volevo condividere esatto con voi questa cosa.Davide mi ha fatto superissimo piacere averti qua con noi, veramente un iper iper iper piacere.anche a me mi sono proprio divertito un sacco poi come già ben mi conosci mi piace parlare quindi saremmo potuti stare qualche altra ora qua in chiacchiere.Grazie di tutto e poi ci rivedremo presto, intanto con te spero presto di persona e poi seguirò assiduamente il podcast per vedere un po' le persone che passano e che sono passate.Grazie, grazie di nuovo.Noi immagino che ci vedremo prestissimo.Grazie davvero di essere venuti qua.Ricordo rapidamente abbiamo avuto con noi il super Davide Fiorello, il decano di noi nirformisti o nirformer.Un abbraccio grandissimo Davide.Ringraziando di nuovo Davide, io vi ricordo rapidamente i nostri contatti info@gitbar.it @bramrap modo canonico, il classico, l'immancabile gruppo Telegram.Se avete del tempo aprite iTunes, andate tra i podcast e metteteci una bella stellina e se vi anche lasciateci una recensione potrebbe non essere importante ma per noi lo è nel senso che grazie a questo riusciamo a tenere saldo la nostra posizione salda la nostra posizione nelle classifiche di iTunes per il podcasting che non è una questione di orgoglio o di dire noi siamo più fighi degli altri ma è questione di raggiungere più orecchie possibile detto questo appuntamento alla prossima settimana ciao Gitbar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.Ciao! Un
