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.Un saluto a tutti gli ascoltatori di finalmente questa settimana riusciamo a andare online per tempo ebbè era ora dopo tante puntate in ritardo e una puntata saltata che però abbiamo in qualche modo ripristinato con la doppia puntata della settimana scorsa comunque bandoleciance oggi andremo a parlare di API e del grande mondo dell'API andremo a parlare di GraphQL.Lo farò subito dopo avervi ricordato i nostri contatti.Potete entrare in contatto con noi iscrivendoci a info@gitbar.it oppure a @brainrepo su Twitter.Bene vi ho detto che inizieremo parlando di API e inizieremo a farlo provando immaginare una situazione il giorno del nostro compleanno e vogliamo invitare il caffè ai nostri colleghi per farlo ci armiamo di pazienza prendiamo le ordinazioni ci dirigiamo verso la macchinetta abbiamo ben 10 caffè da ordinare quindi inseriamo la prima moneta premiamo il pulsante attendiamo che la macchinetta prepari il caffè e ripetiamo questa azione finché tutti i caffè non sono pronti naturalmente dopo dieci minuti da d'attesa per fare appunto tutti i caffè ci rendiamo conto che forse sarebbe stato più bello poter inserire tutte le monete insieme, ordinare tutti i caffè in un solo colpo e attendere la realizzazione per poi ritirarli appunto in un solo colpo.Beh, questo esempio non è poi così pazzo perché ci permette di introdurre il ragionamento delle API GraphQL.Se la nostra vendor machine, la nostra macchinetta del caffè è la nostra API utilizzando un approccio a API REST per avere una risorsa dobbiamo fare una richiesta se poi quella risorsa ha delle proprietà che sono delle risorse a sua volta beh dovremmo fare tante richieste quante sotto risorse dobbiamo ottenere e quindi ci troviamo nella stessa condizione della macchinetta del caffè questo stesso problema lo hanno avuto in facebook attorno al 2012 quando si sono trovati davanti a una delle sfide più grandi per una corporation di quelle dimensioni quella di riscrivere da capo le app in un mondo dove l'utenza standard si stava spostando verso il mobile quindi nasceva l'esigenza di fare delle app in linguaggio nativo ormai la web app che girava su browser non era più sufficiente e quindi da Facebook si decise di ripartire a pensare queste app dal front-end ed è proprio dal processo di studio, prima della UX e poi della UI, si è arrivata all'esigenza di dover ripensare le API.In realtà il passaggio a mobile presupponeva alcune cose un po' diverse rispetto a quello che prima si conosceva.Questa volta, nelle app native, il client poteva avere della capacità computazionale un po' più importante.Cioè, si poteva demandare al client un po' più di calcolo perché, insomma, iniziava ad avere delle prestazioni superiori rispetto al classico browser.Anche perché si poteva avere accesso a API del sistema operativo che, insomma, aiutavano alcuni processi particolari.E poi, avendo questi client così "intelligenti", si doveva però ovviare a un problema tipico dell'API mobile, il problema delle connessioni non stabili.Infatti, proprio le applicazioni mobile ereditano questo limite.Essendo delle applicazioni fruite in mobilità, la connessione può esserci e non esserci.Quindi questa instabilità di connessione portava all'esigenza per il client di conservare dentro di sé, in memoria, una serie di lo stato fondamentalmente dell'applicazione.Ma per andare a comporre lo stato erano necessarie tutta una serie di chiamate rest che iniziavano a essere, insomma, un numero importante.e così da dentro Facebook si è pensato a un modo per superare il concetto di API REST e andare oltre Quando si parla di GraphQL si parla prevalentemente di tre elementi un linguaggio di query, un sistema di tipi e un runtime Quando si parla di query si è portati a guardare direttamente al mondo dei database e di lì vediamo che le SQL la fa da padrone La differenza in realtà tra SQL e il linguaggio di query di GraphQL sta nel fatto che se l'SQL è un linguaggio fatto da istruzioni, quindi un linguaggio di tipo imperativo, SELECT, CERTI CAMPI, FROM, una certa tabella, In realtà il query language di GraphQL è un linguaggio di tipo descrittivo che in qualche modo va a mimare quella che è la risposta che ci si aspetta.Insomma, è un po' come scrivere degli oggetti JSON, dove però al posto dei valori io metto semplicemente i nomi delle proprietà.e questi oggetti possono in qualche modo rappresentare, mimare, degli oggetti che hanno a loro volta delle proprietà che sono degli oggetti.Quindi in realtà riusciamo a fare delle query a più livelli, fino a scendere appunto a oggetti di oggetti di oggetti con una sola chiamata.Cosa in realtà che con le SQL dovremmo andare a fare sì, ma con un numero significativo di join e con una complessità conseguente molto più alta.Per però utilizzare un query language come quello di GraphQL è necessaria una conoscenza importante delle strutture di dati.Ecco perché GraphQL ha bisogno della definizione di un sistema di tipi.Quando noi creiamo un'app GraphQL dobbiamo dichiarare i tipi che stiamo andando a utilizzare e definire la struttura gerarchica dei nostri dati.Vi faccio un esempio.Pensiamo a Facebook.Noi abbiamo "me", infatti la radice di tutto su Facebook è il concetto di "me".Bene, "me" ha una serie di amici che sono delle persone.Ogni persona ha dei post.Vedete che si va a creare un grafo di dati? Bene, questo grafo si può traversare tranquillamente descrivendo un query language, ma lo si può fare solo se si è a conoscenza di questa gerarchia e quindi se questa gerarchia di tipi è stata definita.Io faccio sempre questo esempio quando parlo di gerarchia di tipi.Immaginate di essere liberi di muovervi nel bosco.Vi potete muovere se in realtà nel bosco sono stati tracciati dei sentieri.Bene, la rete dei sentieri è la nostra gerarchia dei tipi.Quindi una volta che noi abbiamo una gerarchia dei tipi possiamo esplorare il bosco senza dover attraversare siepi e fare dei passaggi impossibili.quindi c'è possibile muoverci all'interno della struttura dei dati solo perché la struttura dei dati è stata definita.E infatti la struttura dei dati ci permette, nel momento in cui riceviamo una query, di fare un controllo sui dati richiesti e questo controllo ci permette in qualche modo di verificare che ciò che si sta richiedendo sia consono con la struttura dei dati archiviati nel nostro database e i dati che la nostra API vuole rispondere.Ma sotto il coffano di tutto in realtà c'è un runtime, un motore che prende le query, converte e le valida che e se realizza poi di conseguenza le risposte quindi una sorta di motore sotto il coffano che prende l'ingresso quello che noi stiamo chiedendo e risponde anche perché la struttura graph ql potrebbe rispondere e fittare con una struttura di un db no es quell ma se noi abbiamo sotto il cofano un db e se quelle abbiamo bisogno in qualche modo di un motore che vada a trasformare queste query e questi mutators, che adesso andremo a vedere cosa sono, in richieste base.Che cosa sono le query e cosa sono i mutators? Le query e i mutators sono i due tipi di richieste che noi facciamo alla nostra API GraphQL.Le query, come dice il nome, sono delle richieste che in qualche modo presuppongono un dato di risposta.Cioè io voglio andare a scoprire quali sono i post dei miei amici, ecco bene, lancio una query dove mimo la risposta che mi aspetto e il server mi restituirà l'API, mi restituirà una risposta con una zona coerente con la richiesta che ho fatto.però sapete, nell'API REST esistono anche gli altri verbi, esiste per esempio il POST o il PUT, cioè quelle azioni che vanno a modificare invece la struttura dei dati.Per farlo, GraphQL ci mette a disposizione i mutators, che non sono altro che delle chiamate, alla stessa stregua delle query, che però fanno un'azione attiva.quindi vanno ad agire sulla nostra struttura dei dati, azione che in qualche modo verrà gestita però nel livello sottostante dalla nostra applicazione.In realtà la cosa interessante di GraphQL è che sotto il coffano ci permette di creare un livello d'astrazione che in qualche modo può nascondere le nostre molteplici origini dei dati.dei dati.Un esempio è quello che succede nell'ambito delle applicazioni Twitter.Dovete pensare che l'API di Twitter che implementa GraphQL in realtà ha sotto di sé un motore che va ad attingere i dati, quindi a convertire un reducer, diremo, che va ad attingere i dati da sorgenti completamente diverse, da database o da microservizi.Quindi abbiamo un unico punto di ingresso che comunica in modo semplice palesando offrendo la sua struttura di dati ma che in qualche modo converte questa struttura dei dati in chiamate a microservizi dati che poi una volta presi devono essere integrati tra di loro e c'è una risposta in modo del tutto trasparente quindi in realtà noi grazie a GraphQL non vediamo l'infrastruttura che sta sotto e soprattutto riusciamo ad avere grazie ai reducer dei dati in qualche modo coerenti tra di loro e percepiamo un unico tipo di dato.A questo punto una domanda sorge spontanea.Se io dovessi scegliere tra GraphQL e REST quali sono i pro e i contro.Beh senza dubbio GraphQL ha un query language che è molto vicino al linguaggio del dominio anche perché semplicemente descrive gli oggetti del dominio che noi stiamo andando a prendere secondo la loro struttura di proprietà.Un'altra cosa interessante da vedere e un altro vantaggio di GraphQL è quello che le richieste che in realtà facciamo con REST sono veramente limitate ci permettono di attingere alle risorse in modo molto blindato cosa che invece GraphQL non fa perché nella definizione dell'oggetto che noi vogliamo in risposta abbiamo tutta la libertà dettata da come lo andiamo a rappresentare.E un'altra cosa interessante è appunto che GraphQL permette di attraversare con una sola chiamata l'albero degli oggetti.certo, Grafquel non è il silver bullet, non è il proiettile che ammazza qualunque tipo di mostro ha anche dei contro.in realtà i contro principali sono due.Grafquel avendo uno schema dati di richiesta e di risposta abbastanza dinamico dettato appunto dallo struttura dei tipi quindi tu puoi fare tante richieste quante combinazioni di proprietà ci sono negli oggetti che stai andando a richiedere questa situazione complica la gestione nei sistemi di cache questa gestione però è stata spostata nel motore che gestisce a runtime appunto il reperimento di questi dati prima della conversione in risposta a GraphQL per quei sistemi di cache che possono risiedere a livello dei reducer un altro contro è che avendo una struttura così libera è la possibilità di scendere in profondità negli oggetti di oggetti di oggetti di oggetti l'utente quindi colui che sviluppa il front end attingendo a queste api ha la possibilità di scendere talmente tanti in profondità da immaginando anche in una condizione dove il sistema scala abbastanza però dove ci sono tante richieste ha la possibilità di mandare al collasso le strutture di dati perché ogni volta che noi scendiamo di un livello si complicano le query sottostanti del motore che poi in qualche modo converte gli oggetti e li restituisce in modalità GraphQL quindi con quel formato.Una volta visti i pro e i contro beh buttiamo uno sguardo veloce su quelli che sono i tool che stanno apparendo nell'ecosistema GraphQL.In realtà sono tantissimi molti dei quali sviluppate in javascript il linguaggio diciamo di partenza di questa tecnologia anche se devo dire che la comunità ha apprezzato tantissimo questo white paper scritto appunto dagli sviluppatori di facebook e si è messa al lavoro per scrivere delle versioni sia dei server che dei client di tantissimi linguaggi differenti e oggi ci troviamo infatti con una pletora di tool e di strumenti che vanno a mettere in pratica i concetti di GraphQL.Alcuni di questi sono scritti, come vi dicevo, in JavaScript.Basta pensare ad Apollo.Apollo è una serie di librerie JavaScript che mette a disposizione sia un server GraphQL che un client.O a Prisma, un ORM, ne abbiamo parlato nella puntata dei database del nostro podcast evoluto, però che ci permette di interfacciarci col database attraverso chiamate GraphQL o a relay il client per React per l'utilizzo appunto di API GraphQL.E' un bellissimo tool che in realtà fa parte della cassetta degli attrezzi degli sviluppatori front-end che utilizzano GraphQL che è GraphQL.E' un'applicazione che permette di esplorare l'albero GraphQL dell'applicazione in questione, selezionare i nodi ed è un tool che si dimostra molto utile quando si deve andare a scrivere delle query che devono andare a esplorare un API GraphQL GraphQL è senza dubbio un'API interessante, un approccio all'API interessante.Pensate che è stata inserita persino dentro Gatsby.Il sistema infatti dei dati di Gatsby, dal quale appunto Gatsby va ad attingere i dati, si basa su query GraphQL, query che vanno ad astrarre in qualche modo le varie source sorgenti di informazioni che possono essere il file system coi file markdown oppure un'altra API e insomma quindi sta trovando posto nelle nuove tecnologie.Già società come GitHub, Twitter, Facebook lo implementano per le loro API e sono sempre di più i tool, gli strumenti, le tecnologie, le piattaforme che utilizzano GraphQL per esporre i loro punti d'accesso.Beh, senza dubbio sono sicuro che questo tipo di tecnologia, per la sua semplicità e per la sua vicinanza con quelli che sono gli approcci alla business language, diventerà uno standard industriale.e in attesa che questo succeda noi ci diamo appuntamento alla prossima puntata Anche per oggi è per Gitbar è tutto, io sono Brain Repo, vi ricordo che potete entrare in contatto con me scrivendomi @brainrepo su Twitter oppure a info@gitbar.it vi ricordo inoltre che se per voi questa puntata è stata utile potete aprire il vostro client di podcast, cercare github, sono sicuro che lo troverete e iscrivervi.In questo modo riceverete ogni settimana gli aggiornamenti sulle nuove puntate e rimarrete sempre collegati con noi.Aspetto i vostri messaggi, un salutone da qui, da Lione è tutto, 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 e degli strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica]
