Ciao, e benvenuto nella prima puntata della quarantaquattresima stagione di questo podcast. La scorsa stagione, parlando di API REST, verso la fine abbiamo nominato una via diversa, uno stile in cui è il cliente a chiedere esattamente i campi che vuole. Oggi quella via diventa protagonista: si chiama GraphQL, ed è il tema di questa stagione. Ma attenzione: non è semplicemente un REST migliore, e non è una questione di sintassi. È un modo diverso di pensare a come i programmi si chiedono i dati. Oggi capiamo cos'è, e soprattutto quale problema è nato per risolvere.
Partiamo dal problema, perché GraphQL è nato da un dolore concreto. Ricordi il limite più noto di REST? Ogni cosa aveva la sua fotografia a taglia fissa, decisa dal server. E questo portava spesso a due fastidi: ricevere troppo, un mucchio di campi che non ti servivano, oppure troppo poco, dovendo fare tante richieste separate per raccogliere pezzi sparsi che ti servivano insieme. Su un telefono, con una rete lenta, questi due problemi fanno male davvero: sprechi dati, e aspetti tanti viaggi. Ecco, GraphQL è nato dentro una grande azienda di social network, proprio per curare questo dolore, sui suoi milioni di telefoni.
Voglio darti l'idea radicale che propone, perché è tutta qui. La soluzione di GraphQL è una sola idea, semplice e rivoluzionaria: lascia che sia il cliente a chiedere esattamente ciò che vuole, né più né meno, in una sola richiesta. Non è più il server a decidere la forma della risposta, consegnandoti pacchetti a taglia fissa. Sei tu, che chiedi, a descrivere la forma esatta che ti serve, e il server te la restituisce, cucita su misura. Se ti serve solo un nome, chiedi il nome e ricevi il nome. Se ti servono dieci cose collegate tra loro, le chiedi tutte insieme e le ricevi in un colpo solo. Il potere di decidere la forma passa dal server al cliente.
Voglio spiegarti il nome, perché racconta la seconda idea chiave. GraphQL: le ultime lettere stanno per linguaggio di interrogazione, cioè un linguaggio per fare domande, per chiedere dati. E la prima parola, grafo, è il cuore concettuale di tutto: i tuoi dati sono un grafo, cioè una rete di cose collegate le une alle altre. Un utente è collegato ai suoi articoli, un articolo ai suoi commenti, un commento al suo autore, che è di nuovo un utente. Tutto è una trama di collegamenti. E GraphQL ti lascia percorrere questa trama in una sola richiesta, seguendo i fili da una cosa all'altra. Chiedere dati navigando un grafo di cose connesse: è questa l'essenza.
Voglio darti la lente della stagione, perché tiene insieme tutto. La lente è questa: con GraphQL, chiedi esattamente ciò che ti serve, trattando i dati come un grafo di cose connesse che percorri in una sola richiesta, con la garanzia di uno schema. Dove REST ti serviva piatti già pronti a indirizzi diversi, GraphQL ti mette in mano la penna per scrivere il tuo ordine preciso, e lo esaudisce percorrendo la rete dei tuoi dati. È uno spostamento di potere e di prospettiva: dal server che decide, al cliente che chiede; dalle cose separate, al grafo connesso.
Voglio essere onesto fin da subito, perché è nello spirito di questo podcast. Ti dico chiaramente una cosa, così non ci saranno malintesi per tutta la stagione: questa non è la storia di GraphQL che batte REST. Non esiste un vincitore. Come dicemmo, e come ripeteremo, sono due strumenti diversi, con compromessi diversi, ciascuno bravo per una certa forma di problema. GraphQL risolve elegantemente certi dolori, ma se ne porta dietro altri, che vedremo con altrettanta onestà. Sono due risposte complementari alla stessa domanda: come dovrebbero i programmi chiedersi i dati. E imparare entrambe è ciò che ti fa scegliere con la testa.
Voglio anticiparti dove andremo, perché il viaggio ha una direzione. Nelle prossime puntate scaveremo dentro questa idea. Vedremo come il cliente tiene la penna e disegna la forma della risposta. Come i dati sono un grafo da percorrere. Come uno schema, una mappa tipizzata, garantisce tutto e descrive sé stesso. Come si passa da una sola porta. Come si legge, si cambia, e si resta in ascolto. E arriveremo, onesti, ai costi di questa libertà, e a quando conviene, e quando no. Un passo alla volta, tenendo sempre a mente la penna in mano al cliente, e il grafo da percorrere.
Per oggi ci fermiamo qui. Abbiamo aperto la stagione su GraphQL, nato per curare un dolore reale di REST: ricevere troppo, o troppo poco, con tanti viaggi. La sua idea radicale è lasciare che sia il cliente a chiedere esattamente ciò che vuole, in una sola richiesta: il potere di decidere la forma passa dal server al cliente. E il nome racconta il resto: un linguaggio per interrogare un grafo, cioè una rete di cose collegate, che percorri seguendo i fili. Con la promessa, da subito, di non tifare: GraphQL e REST sono due risposte complementari, non un vincitore e un perdente. Nella prossima puntata vediamo la prima idea nel dettaglio: chi tiene la penna. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.