Ciao, e benvenuto nella seconda puntata della quarantaquattresima stagione. Nella scorsa puntata abbiamo detto che l'idea radicale di GraphQL è lasciare che sia il cliente a chiedere esattamente ciò che vuole. Oggi entriamo dentro questa idea, perché è la prima e più definitoria, quella da cui discende tutto il resto. Riguarda una cosa semplice ma profonda: chi tiene la penna. Chi decide la forma della risposta, il server o il cliente? La risposta di GraphQL ribalta l'abitudine, e cambia tutto.
Partiamo da come faceva REST, perché il contrasto illumina. Ricordi le rappresentazioni, le fotografie delle cose? In REST è il server a decidere come è fatta ogni fotografia: quando chiedi un utente, ricevi la scheda dell'utente così come il server ha deciso di comporla, con tutti i suoi campi, che ti servano o no. Tu prendi quello che ti danno. La forma della risposta è decisa da chi risponde, una volta per tutte, uguale per chiunque chieda quella cosa. Il cliente non ha voce in capitolo: accetta il pacchetto preconfezionato.
Voglio darti il ribaltamento di GraphQL, perché è tutta qui la sua essenza. GraphQL capovolge chi tiene la penna. Non è più il server a decidere la forma: è il cliente. Quando fai una richiesta, tu descrivi esattamente quali campi vuoi, e quanto in profondità, e il server ti restituisce esattamente quella forma, né più né meno. La risposta rispecchia la richiesta come un'eco. Chiedi solo il nome di un utente? Ricevi solo il nome, nient'altro. Chiedi il nome, l'email, e il totale del suo ultimo ordine? Ricevi esattamente quelle tre cose, in un unico oggetto pulito, senza sprechi. La forma che chiedi è la forma che ottieni.
Voglio farti apprezzare cosa questo risolve, perché sono i due dolori di prima. Questo ribaltamento cura di netto i due fastidi di cui parlavamo. Il troppo sparisce: non ricevi mai più campi di quelli che hai chiesto, perché chiedi solo ciò che ti serve. E il troppo poco sparisce: puoi chiedere in un colpo solo tutto ciò che ti occorre, anche cose collegate, senza dover fare tanti viaggi separati. La schermata che stai costruendo sa di cosa ha bisogno; la richiesta lo dice con precisione; la risposta arriva su misura. Niente peso morto, niente andirivieni: esattamente ciò che serve, e nient'altro.
Voglio farti apprezzare perché questo sia più giusto, perché tocca un principio profondo. Chiediti: chi sa meglio di cosa ha bisogno una schermata? Non il server, che serve mille clienti diversi e non può conoscere le esigenze di ciascuno. Lo sa il cliente, quella specifica schermata, che sa esattamente cosa deve mostrare. Ecco il punto profondo: GraphQL sposta la decisione di quali dati verso chi possiede la conoscenza per prenderla. Il server non può indovinare le esigenze di tutti, e finisce col dare a tutti lo stesso pacchetto, buono per nessuno in particolare. Il cliente, invece, sa. Mettere la decisione dove sta la conoscenza è quasi sempre una scelta migliore.
Voglio darti l'immagine che rende chiara questa idea, perché la riconosci. Pensa alla differenza tra un menù fisso e ordinare alla carta. Il menù fisso ti serve un piatto già composto, deciso dalla cucina: prendi quello, con i suoi contorni, che ti piacciano o no. Ordinare alla carta significa scrivere tu, sul foglietto, esattamente cosa vuoi, nelle porzioni che vuoi, e ricevere quel piatto preciso. REST è il menù fisso, la cucina decide; GraphQL è alla carta, decidi tu. E chi sa meglio cosa hai voglia di mangiare, se non tu? Tieni tu la penna sull'ordine.
Voglio trarre la lezione generale, perché va oltre GraphQL. C'è una verità di progettazione, qui: lasciare che sia la parte che conosce le proprie esigenze a specificarle, spostare la decisione dove sta la conoscenza, batte spesso una soluzione unica servita d'ufficio dall'altra parte. Quando chi decide non conosce i bisogni reali, finisce col fare compromessi buoni per nessuno. Quando invece decide chi sa, la risposta è su misura. Vale per le API, ma è un principio generale: dai la penna a chi conosce il problema, e otterrai soluzioni migliori di quelle imposte da chi il problema lo vede solo da lontano.
Per oggi ci fermiamo qui. Siamo entrati nella prima idea, la più definitoria: chi tiene la penna. In REST è il server a decidere la forma di ogni fotografia, uguale per tutti; GraphQL ribalta tutto, e lascia che sia il cliente a descrivere esattamente i campi che vuole, con la risposta che rispecchia la richiesta come un'eco. Così spariscono sia il troppo, mai più campi inutili, sia il troppo poco, tutto in un colpo solo. Ed è più giusto, perché sposta la decisione verso chi conosce i bisogni: il cliente, non il server, come ordinare alla carta invece che dal menù fisso. La lezione: dai la penna a chi conosce il problema. Nella prossima puntata vediamo il cuore concettuale: i dati come un grafo. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.