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 i nostri contatti e possiamo iniziare.

Info chiocciola Geekbar.it e The Brain Repo su Twitter sono i modi canonici per contattarci, anche quelli che ormai non usa più nessuno.

A perchè la mail, no è bella e palle scrivere le mail.

B perchè tanto Twitter sta fallendo e non masco meno 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' Vanna Marki, io direi che possiamo iniziare, quindi sigla.

Benvenuti su Geekbar il podcast dedicato al mondo dei full stack debelter, 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, no? È 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ì, ciao a tutti, hai detto benissimo.

Grazie Mauro intanto per la presentazione, ho visto che hai ricordato Alicante, ho di recente ascoltato la puntata e ho visto che ha colpito e lasciato nel cuore di molti, di molti, tanti ricordi.

Mi compiace molto 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 Davide, ormai è già da un po' un 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, no? 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 format, se ve lo siete persi andatevelo a recuperare perché è esilarante, lo chiamammo GitFighter 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 barra 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, è arrivato 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 e sì 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 e 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 a, non è insegnabile perché quello 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 è una considerazione.

Quando per la prima volta approcciamo una tecnologia, in questo caso è GraphQL ma potrei dire la stessa cosa di Rust 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 tipo 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 è, com'è 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 forma, prima di questa esperienza da Commodore Remote Worker dall'ufficio di casa mia, ho lavorato, 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 angular JS, lavoravo in KLM, l'airline, e 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? 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 una volta.

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 mixins in React, adesso non so in quanti li abbiano mai visti, e usavamo Fluxore come state management, Redux non esisteva, quindi subito a ruota Facebook è uscito con la presentazione GraphQL, GraphQL che ho iniziato ad 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 le 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, ci hanno lasciato la libertà di scegliere e mi hanno preso nel momento in cui io volevo mettere GraphQL, perché avevo bisogno di provarlo da qualche parte, ho fatto un po' questa follia da un cliente di queste dimensioni.

Minchia 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 era già uscito Apollo, 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 nell'interfaccia ci ha aiutato tantissimo.

All'epoca la complessità era nel front-end, ultimamente ho nominato Mercurius, i miei progetti recenti sono molto più sul front-end.

Poi su Mercurius ci andiamo perché ho avuto modo di sfagiolare un po' la codebase ancora prima di un refactoring recente che è stato fatto, 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ì, tra l'altro 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, e 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, che è in questo caso GraphQL, GraphQL 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 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'erano.

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 jingle.

La domanda è, tu hai detto, talvolta io mi butto e in produzione magari ci tiro dentro una tecnologia innovativa, anche io l'ho fatto, non l'ho fatto con la tecnologia, l'ho fatto con un, non so, una metodologia, un pattern chiamiamolo così, col 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 di sta 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? E tipo 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 in produzione.

La valutazione è stata fatta considerando che non era un progetto ad alte performance, che richiedeva alte performance.

Quindi io non lo sapevo quanto GraphQL fosse performante bene.

Sicuramente non era una roba che richiedeva delle performance, perché avevamo un, noi gli italiani chiamano FF, front end for back end, era un FF, front end for back end.

Quindi era un servizio che chiamava delle API dietro, lentissimi, perché immaginati tu vai a prendere dei dati molto complessi, noi facevamo i pacchetti, quindi tu dicevi dove devi 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 API 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 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.

Quindi erano tre chiamate, quattro chiamate, ma con delle strutture enormi.

Quindi allora tanto vale che ci provi e andate bene.

Perché alla fine ci è tornato molto bene, non avevamo mai usato Apollo sul frontend 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, non ho paura a dire adesso scusate datemi una settimana per rimediare a quello che è stato fatto.

Alla stessa maniera, come raccontavo all'inizio, noi scegliamo React per fare questo progetto in KPLM quando tutta l'azienda usava Angular.

Quindi noi proprio, Valespa, Valdi...

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 dall'abbrivio dato dalla moda, 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 applicazione 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 applications.

Noi lavoriamo in un mondo in cui imbarba, ricito una cosa che abbiamo discusso di recente in un altro accolo in inglese che citavamo prima, imbarba a tutti i progetti, questa cosa la si fa così, tempo perso a fare dei grafici e a decidere come fare il database, il software web moderno lo decide il designer che sia un produttore.

Punto, non giriamoci attorno, c'è un produttore, parlo ovviamente di una situazione semplice, poi quando si parla di grandissime applicazioni ci sarà un più produttore, un 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 produttore che li guida, che ha in mente una feature e semplicemente loro mettono su una feature.

Partendo dai design si fa il resto, perché così alla fine si fanno, almeno nelle mie esperienze penso che… No, si fanno le cose.

Sì, cioè 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 il 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, mantenimento, sul mantenimento potrei parlare male di GraphQL però… No, ma poi ci arriviamo perché mi sono appuntato un punto proprio su quello.

Bravo, però sulla fase di progettazione, sulla fase di progettazione, GraphQL è fenomenale, ogni tool che ci sono in giro, che velocemente da un database o da una struttura dati ti creano, parto dal platformatic di Matteo Collina, 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 forniscendo l'API, tu hai la possibilità veramente in maniera veloce di tirar su un servizio che va e con le varie librerie che ti si attaccano a React rendono veramente velocissima la prototipazione, è una roba, è impressionante fare il 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 di performance, avremo l'intera puntata per descrivere 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, cioè si fanno grandi cose.

Si, hai detto, ah scusa, vai, vai.

No, volevo dire, semmai la riprendiamo dopo, perché questo apre una voragine.

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 è la migliore 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 su quelle tecnologie.

Vero, 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 produttore, ok, e dal UX, il designer.

Io ho detto designer, ma con designer intendevo tutto quel messione 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 sviluppatore abbiamo la presunzione di dover dettare una riga, no, di dire no ma questo non si può fare, posto che quello che mi disse il mio produttore è la prossima volta che mi dici non si può fare ti prendo a calcino 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 il mio fratello è un architetto, il 90% del mio fratello è da fare i progetti, avere più o meno idea dei calcoli e della parte strutturale, poi lo dà in mano a un ingegnere e gli dice, come, vi faccio questi, prova a costruirvi queste immagini, prende un pezzo di carta, lo appallottola e dice voglio questa struttura del cazzo tutta 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, noi dovremmo essere quelli che al ecco fammela stare in piedi, dobbiamo saper dire sì, io 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 contro TypeScript? 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! 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'è Empoint 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 e 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, poi in realtà li puoi sanitizzare, puoi validarli, puoi fare un sacco di cose, tra l'altro schema non è che GraphQL permette di fare anche mille validazioni, permette di fare tante cose, su quelle directing fondamentalmente fai tutto quello che fai anche sempre, però è di base, è naturale, ha una dipendazione molto basilaria, che però fa, come dici tu, detta delle regole, detta delle regole che lo sviluppatore JavaScript, in cui motto spesso è quick and dirty, più dirti che quick tavola, 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 li puoi 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 questa 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 c'è, 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 crud, 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.

È da 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 della 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 engine su cui GraphQL 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 i problemati di reloading, di caching, tutta una serie di cose.

La cosa veramente secondo me figa di GraphQL, da questo punto di vista, è che tu il singolo dato puoi andare a mettere la logica nel singolo dato, ok? E il 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 sistema di caching un po' di fregartene dell'andare a pescare un dato.

Quante volte tu vai a pescare i dati oppure li metti nella query, scusa, li metti nel codice perché non vuoi andarli a richiedere tutte le volte, con un sistema di caching ben fatto.

In realtà poi il sistema di caching non fa neanche il resto.

Diciamo che GraphQL ti forza un po' a fare certi shape, questo non è un vantaggio perché alla fine è una forzatura, però ti abitui un po' a lavorare con queste cose e quindi 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 ti fa benissimo il resto e la fai dappertutto.

Con GraphQL tu puoi tranquillamente nel tuo resolverino fare questa cosa fregandotene delle performance perché tanto un sistema di caching o di preloading 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ì, alla fine è una funzione come un'altra, non è che ci siano delle cose speciali, cioè non ti facilita.

Tu hai un ingresso e dei resolver, punto, hai dei dati e ogni dato ha un resolver.

Questo resolver ti restituisce uno scalare se uno scalare, ti restituisce una struttura o qualcosa del genere se all'interno di questo attributo è un altro oggetto e così è cascata, tu puoi fare le cose e avere dei risultati che nella mia esperienza funzionano.

Poi se tu fai un node che restituisce un JSON statico è più veloce.

Tieni presente che devi anche stare attento a cosa usi per serializzare il JSON.

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 frontend senza farci niente di quella deserializzazione, ci creava un sacco di problemi, perché con la deserializzazione costava 50ms.

Per uno non è un problema, ma quando tu questo JSON lo carichi, sono 50ms di processore, non sono i 50ms di await.

La deserializzazione di JSON e la serializzazione di JSON è sempre facile e molto attento.

Noi ci andiamo molto rapidi là sopra, però in azienda ne abbiamo viste di specie quando le performance contano.

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 chiedere al database, al backend, 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.

In questo approccio quali sono secondo te i vantaggi più grandi e quanto invece i calci nel culo che ne derivano da questa approccia? 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 con un server GraphQL.

Si tirano giù i server in questa maniera e non sto scherzando.

E volevo portarti a parlare proprio di quello.

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, e 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 hai bisogno anche dell'indirizzo e 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 front-end 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, è una sorta di...

è il modo che ha GraphQL per definire un seme 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 fare l'indirizzo, 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.

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 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 li avete mai visti i full stack, perché io di full stack ne ho visti tanti e ho lavorato con tanti full stack.

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 back end.

Io che ho avuto la fortuna negli anni di lavorare un po' a destra, un po' a sinistra, o a sopra e sotto, prendendo i front e i 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 si vado a prendere poi ci penserò e queste ha dei costi trementi, serializzazione e serializzazione, richiesta di database.

Se tu hai un DynamoDB dietro, che costa a richiesta, è ovvio, se tu hai un DynamoDB è molto cheap se tu fai poche richieste, 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 e avere 10 fa la differenza.

Quindi ci sono delle attenzioni a cui bisogna stare attenti.

Si sbaglia tutti, io per primo faccio del castronato, ogni tanto, che è veramente sbattere 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, ti frega, tu chiami una REST API, sai già che tanto 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 per il parametro full response o qualcosa? Si, o complete.

Allora usa GraphQL.

Nel momento in cui devi dire che tipologia di dati vuoi dietro, usa uno strumento che è fatto per queste cose.

Si, 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 le so le motivazioni esatte.

Conosco molto bene Mercurius, so che è fatto da un maniaco delle performance e quindi a 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 Sharp 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 code.

C Sharp, dico C Sharp perché durante le vacanze di Natale, nelle mie due settimane di vacanze, ho lavorato per Unity a full time.

Sto facendo un giochino per i fatti miei perché mi rilassa e quindi ho dovuto lavorare molto in C Sharp che non conosco.

L'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? Io il JSON lo carico e lo uso in JavaScript e in TypeScript.

In C Sharp devo fare un serviziatore, una serie di robe che vanno fatte e poi verrò smentito da gente che C Sharp lo conosce, perché io c'è quel fatto, non lo conosco.

Però così a naso mi viene da dire che GraphQL è nato per essere fatto dal 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, dovrebbe che 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, si vede la differenza.

Sono due prodotti diversi.

Diversi dal punto di vista dell'utilizzo.

Poi Apollo è amato ovviamente da chi entra nel mondo Node, perché se fai una ricerca ti viene Apollo e il mondo Node.

Anche perché è un prodotto commerciale supportato da...

Tutta una serie di cose.

Però, adesso butto l'acqua un po' al mio di mulino.

Se dovessimo usare un server, a questo punto useremmo Express se ragionassimo con questo sistema.

La differenza è che Apollo ha un'azienda, dietro Express no.

Per quanto sia proprietario dell'IBM, fra una serie e tutta una serie, che l'hanno vinto a carte 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 un certo punto mi sembra che fosse sotto un prodotto che l'IBM ha comprato.

Comunque, dettagli.

Però se noi dovessimo fare un server useremmo Express da questo punto di vista.

Quindi invece Fastify, che se non conoscete la community di Fastify, adesso a parte Matteo e io...

La conoscono, la conoscono.

Rompo le balle io.

No, è un prodotto fenomenale dal punto di vista della community.

Cioè è 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...

Scusate, Mercurius c'è Fastify.

Non è che non usate Fastify se usate Mercurius.

Però è un prodotto ben supportato.

Fatto bene, fatto che funzioni.

Ha i suoi bug, ma ce li hanno 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, federazione, con dieci nodi.

Non sto parlando di un serverino che serve tra entità.

Parliamo di una roba...

Abbiamo fatto una migrazione da Apollo a Mercurius e il passaggio...

Abbiamo tolto due cose, Sequelize, che era una versione vecchia, e Mercurius.

Sequelize e Apollo.

La rimozione di Sequelize, che era una versione vecchia che usava ancora Bluebird.

Oh mio Dio.

Esatto.

Tappava non poco.

Il passaggio Mercurius, che ci ha permesso di andarci un po' più spinti con il sistema di cache, con queste cose, ha fatto la differenza.

Il sistema era oggettivamente più veloce, ma molto più veloce.

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, loro te lo danno.

Quindi si può fare.

È 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 Federale.

Hai diviso il gemello Siamese.

Ho diviso il gemello Siamese.

Hai tirato fuori tutta la parte di Federation perché era strettamente accopiata a Mercurius.

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, come ne male, è quello.

Sul Gateway l'ho estratto e ho dovuto fare un po' di ritocchi perché non era sufficiente estrarlo.

Cioè ci sono andato un po' a fondo, ma è stato molto utile perché questo mi ha permesso di andare nel core.

Infatti dopo che l'ho fatta, 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 che il problema era da risolvere.

Dopo ho iniziato a chiudere un po' di task.

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, quindi probabilmente conosci quel ticket che hai girato in azienda per un po', forse è il nostro amico Simone al quale mandiamo un grande abbraccio, è stato l'ultimo a cui 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 certo poi come 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 consulenza.

Quindi per me era una novità abbastanza, quindi ho avuto occasione di rimetterci le mani e la federazione sì ne avevo sentito parlare ma non l'avevo mai fatta.

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 hanno 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 fornirne l'identificativo e poi c'è un sistema di gateway che altro non fa che interrogare tutti questi servizi che tu dichiari all'inizio e lui uno per uno prende questo schema, lo mergea in un'unica grande schema e fa vedere all'utente finale un'unica macchina che lo usa appunto come se fosse un'unica macchina.

E queste cose ti permette di fare grandi cose, ti permette di avere un bel storm di nodi su Kubernetes per esempio in cui i due servizi che hanno bisogno di potenza hanno 24 o 36 nodi e il servizetto che non viene usato poca niente, ogni tanto, gli mette solo uno senza dover necessariamente replicare un'unica macchina 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 quando lavoravo in KPLM, la home page di KPLM all'epoca ci saranno stati almeno 6 team, 7 team che lavoravano per buttare fuori quei dati di quella home page, fra back end, fra front end, c'era un gruppo che faccia solo l'header, c'era tutta una serie di cose e questa è la normalità, quindi nel back end avere la possibilità ognuno di lavorare sul proprio porticello fa una bella differenza e non è solo una questione di dimensione del progetto.

Quando tu hai 10 team di 3 persone, 1, 4, stiamo sul piccolo back end, quando tu hai 3 per 10, 30 persone che lavorano sulla stessa home page, poi puoi fare le merge, si diverte, c'è tutta una serie di lanciare i test di una code base in cui lavorano 10 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.

Mercurius la fa bene, è ai livelli di completezza di quello di Apollo? No, non lo è, perché l'hanno inventata quelli di Apollo, cioè le specifiche della federazione.

Mercurius non implementa la federazione, implementa la federazione V1 di Apollo, quindi l'hanno inventata quelli di Apollo.

Ero finito delle specifiche per capire come cazzo funziona, 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 era implementata, ce l'ha sia implementata.

No, no, no, ci ho girato attorno senza problemi, ancora all'epoca non avevo questa conoscenza della code base 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.

Non sto dicendo con la zappa, però fondamentalmente questo fanno.

In più c'è un terzo elemento che è un query, possiamo vederlo come un query, che in qualche modo parla attraverso un altro protocollo, possiamo immaginarlo come WebSocket, e qui ti permette di rimanere in ascolto di qualcosa che poi ti arriva e non è strettamente legato a un processo di richiesta risposta.

L'ho detto con la zappa, Davide.

Esatto, è un sistema di push che si usa con GraphQL.

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à, ancora 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, sai 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 limit 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 controcasti, 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 realistico.

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.

Esatto, però tramite CloudWatch, c'è un sistema che si chiama Ray, è qualcosa che ti permette di vedere il giro che ha fatto la richiesta per i vari servizi.

Comunque 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.

Può fare anche App Insight.

Esatto, immagino che lo facciano.

Cioè, sono alla base queste cose.

Quindi le metriche, tutta una roba essenziale.

Adesso sto lavorando, lo ricito, con Simone Sanfratello, che è molto bravo da questo punto di vista.

Cioè lui su metriche, sull'andare a dire a questi sistemi che cosa sta succedendo dentro il codice, è proprio una cosa che gli piace, si vede, gli brillano gli occhi quando ti racconta queste cose.

Tanto sarà ospite prossimamentissimo, quindi lo sentirete tra pochissimo.

Quindi lui è proprio bravo.

Io per esempio sono più sull'architettura, su queste cose ad alto livello, lui sul basso livello è un fenomeno.

Quando metti i dati come si deve, tu recuperi tutte le informazioni che ti servono.

Quindi sai esattamente le cose come funzionano.

Poi dove non ci arriva l'infrastruttura, inteso come la VU, cioè l'infrastruttura, dove non ci arriva il tooling fatto da altri, ci si smazza e si inventano cose.

Io ho finito il progetto dopo un anno in cui sono passato sul nuovo progetto, nei due mesi di pausa fra 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 NearForm, noi l'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 com'è fatta, cosa che in Mercurius mancava, non so se c'è in Apollo, ma adesso abbiamo un sistema che è dato una federazione e 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 e dici ma chi è che lavora a questo nodo, dà un'occhiata che lo chiedo a tizio.

Quella è una roba che tu se vedi solo lo schema finale non sai dove questa cosa viene fatta.

Questa è la prima parte, prima cosa che abbiamo fatto e l'altra, una cosa essenziale, è che abbiamo fatto un plugin 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 cinque volte.

Tu dici come mai è stato chiamato cinque volte e vai a vedere e dici che qualcosa non è andato.

Allora vai un po' a sistemare e ti rendi conto che spesso i problemi sono nel codice.

Oppure vedi che il resolver ci mette troppo tempo e 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é riduci la complessità.

Esatto, riduci 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 rispondere con una sola parola, Redis.

Ha scritto anche un tweet su questo.

Io l'ho sempre usato molto, molto, diciamo di paro dei 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 in cui ho fatto questa federazione, in cui ho lavorato a stretto contatto con Matteo per un bel po', 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 so usare Redis, ho imparato a sfruttarlo molto bene, questa è la parte importante.

E' una cosa che dovrebbe far parte di una, cioè Redis dovrebbe esserci non il progetto.

Un progetto che non ha un Redis è un progetto che non ha bisogno di performance, perché performance non intendo che deve restituire in 20 millisecondi una pagina, però spesso e volentieri...

Se c'è complessità c'è fai dati, 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 10 minuti di andarlo a prendere da Redis e me ne frego di quanto costi il reale peso.

Ed è una cosa che ti fa programmare con molto più leggerezza da questo punto di vista.

Con il cash 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 mai...

Va tutto in vacca! 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, qualcosa sotto il culo, i dati sotto il culo ti sono cambiati! Anche poi lavorando nell'ambiente le scopri queste cose.

Io 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 sono già tre giorni e che non ci sono più? Ma un utente interno dell'azienda, uno a cui abbiamo chiesto, e lui ci ha detto che la pagina era riaperta da una settimana e io semplicemente a un certo punto ho deciso di dire ok.

Guarda, caso di stamattina, giusto per farci una risata insieme, caso di stamattina io sto lavorando un sistema e 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, cos'era successo? Una persona si era aperto, 50 prodotti, ok 50, 100 tab, uno con ogni prodotto, che non erano prodotti, questi prodotti sono scaduti, quindi non erano più presenti e lui ha praticamente lanciato, non so se fosse uno script o qualcosa, uno schedula call per tutti i prodotti e quindi io guardando le app in site ho detto ma questo è un coglione, invece no, se tu pensi a livello di business, io mi immagino, sai ho avuto 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 bookare aperti, bookare non credo si dica neppure, ma facciamo finire.

No, bookie, boo boo boo e bookare.

Prenottare, prenottare.

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, io direi che potrei rimanere ore a parlare di questo, l'abbiamo anche già fatto.

Vi 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 questo API GraphQL era cercare di stabilire un contratto tra front-end e back-end 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? Tanto 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, all'architecture e gli 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 nullo, questo è uno dei grandi problemi.

E l'errore non è lì, ce l'hai separato, ce l'hai da un'altra parte 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 dire il vero.

Però sì, hai ragione, non c'è una soluzione, che io sappia, non c'è una soluzione.

Ti dico come avevamo fatto noi, avevamo messo tutto dentro un bel try and 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ì.

Ma ti faccio una domanda, tu chiedi una lista di 10 prodotti, il terzo prodotto della lista ti ha dato un errore e quindi è nullo.

Perché si è rotto e quindi non c'è nessun 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 è un po' che 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, ho una classe stupida con queste due proprietà e poi io faccio, 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 di booking che ti dice, immagina che stai facendo un pacchetto 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.

Ecco, una cosa che ho visto dei tool GraphQL è quella.

Secondo me c'è un po' di lavoro a livello 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, non c'è una grande pressione di farlo evolvere, questo è vero.

Alla fine ci sono cose nuove, Apollo ha portato delle grandi cose, le subscription inizialmente erano un'idea, non esistevano, poi lentamente le hanno definite e buttate dentro.

Non è velocissimo come sistema, quindi, come specifiche.

Quindi aggiungere, fare la roba che richiedi implica che tu la devi mettere in specifiche, cioè il fatto che se un'entità non viene restituita tu potresti avere l'errore sul posto.

Questa è appesante come affermazione.

È bisogno 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, io nel caso se ho un errore, ti mostro l'errore, si fa.

Vuoi fare un hacking da questo punto di vista, lo fai.

Il problema è che se tu non lo richiedi, quell'errore lui non ti da indietro.

Invece, appunto, lo metto tu, di base ti da una strutturina separata con un elenco degli errori in cui ti dice c'è stato un errore X in questo punto, cioè ti dice proprio c'è stato un errore X in questo punto, quindi tu devi anche andarti a ricostruire dove c'è stato questo errore, che il 90% delle volte te ne freghi e dici c'è stato un errore e non mostri i dati.

Ma se sei federato 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.

Sei sparito completamente.

Allora datemi giusto un secondo, prima di andare in chiusura, perché abbiamo un momentino che non possiamo sboccare.

È 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, 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, 3 birre 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ì, 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.

Assolutamente.

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ò vi ricordo che 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.

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 ciò il regalo giusto.

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.

È la prima volta che lo sento.

È un libro, 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 intermezzi che ci sono fra un capitale e l'altro, che in quello per ottimisti sono più ottimisti e quello per pessimisti sono un po' 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, il 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 ho veramente divorato, su un mondo distopico, però divertente, perché 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.

Allora, 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 è, non lo so, 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 fatto alcune parti dell'università un po' alla cazzo di cane, speciale a 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, c'è veramente un gozziliardo.

Se avete bisogno di una lettura un pochino più pesante, ecco, qua probabilmente avete il repository 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 adesso 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 nearformisti o nearformer, un abbraccio grandissimo Davide.

Ringraziando di nuovo Davide, io vi ricordo rapidamente i nostri contatti, infochiocciola.it, brandrepo in 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 va 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 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 possibili.

Detto questo, appuntamento alla prossima settimana.

Ciao! Sottotitoli e revisione a cura di QTSS.