Ciao, e benvenuto nella nona puntata della quarantaquattresima stagione. Nelle scorse puntate ho raccontato GraphQL con ammirazione: la penna al cliente, il grafo, lo schema. Ma oggi, come sempre verso la fine, mettiamo sul tavolo la verità onesta. La flessibilità di GraphQL è reale, e reali sono i suoi costi. Ogni libertà che dai ha un prezzo, e conoscerlo è ciò che ti fa scegliere con la testa, non per moda. Oggi vediamo i costi di GraphQL, e quando conviene non usarlo.
Partiamo dal primo costo, la memoria di scorta, perché è il più concreto. Ricordi che in REST tenere le risposte in memoria di scorta era facile e gratis? Perché ogni cosa aveva il suo indirizzo fisso, e un indirizzo fisso è facilissimo da riconoscere e riusare: chiedi due volte la stessa cosa allo stesso indirizzo, e la seconda te la servi dalla scorta, senza rifare il lavoro. Con GraphQL, una sola porta e richieste sempre diverse, quella facilità sparisce. Non puoi più riconoscere al volo due richieste identiche guardando l'indirizzo, perché l'indirizzo è sempre lo stesso. Tenere le risposte di scorta si può ancora, ma diventa un lavoro più complicato, che ti devi costruire. Una comodità che avevi gratis, ora la paghi.
Voglio darti il secondo costo, l'arma a doppio taglio, perché è il più insidioso. La complessità si sposta sul server, e in un modo pericoloso. Qualcuno deve far funzionare il raccogliere dietro le quinte, di cui parlammo. Ma soprattutto, e qui sta il punto affilato: un cliente ora può chiedere qualcosa di rovinosamente costoso. Può chiedere di percorrere tutto il grafo, in profondità, cosa dentro cosa dentro cosa, e mettere in ginocchio il server, per sbaglio o anche di proposito, per fare danno. La libertà che hai dato al cliente è anche un'arma carica. Quindi il server deve difendersi: mettere dei limiti, a quanto in profondità e quanto costosa può essere una richiesta. La flessibilità va recintata, o si ritorce contro di te.
Voglio darti il terzo costo, l'eccesso, perché è il più comune. Spessissimo, GraphQL è semplicemente troppo. Se la tua API è semplice, poche cose lineari, un solo tipo di cliente, allora lo schema, il raccogliere, tutto l'apparato di GraphQL sono un cappotto pesante in una giornata mite. Un semplice REST sarebbe più facile, e più che sufficiente. Tirare in ballo tutta la macchina di GraphQL per un problema piccolo è come le altre volte: sovradimensionare, portarsi addosso una complessità che non serve. La potenza di GraphQL ha senso solo se il tuo problema ha davvero la forma che la richiede.
Voglio allora dirti quando conviene davvero, perché è il rovescio giusto. E qual è questa forma? GraphQL guadagna il suo costo quando hai dati davvero complessi e profondamente connessi, un grafo intricato da percorrere. Quando hai tanti clienti diversi, il sito, l'applicazione sul telefono, i partner esterni, ciascuno che ha bisogno di forme di dati diverse. E quando le esigenze del frontend cambiano di continuo, e senza la penna in mano al cliente dovresti modificare il server a ogni piè sospinto. È il suo terreno d'elezione. E, guarda caso, è esattamente per questo che l'azienda che l'ha inventato lo fece: tanti telefoni diversi, un grafo sociale complesso, esigenze in continuo movimento.
Voglio darti la bussola, perché è la lezione di sempre. Torna la verità che questo podcast ripete: non esiste lo strumento migliore in assoluto, esiste quello giusto per la forma del problema. REST e GraphQL non sono rivali da incoronare l'uno contro l'altro: sono strumenti diversi per problemi di forma diversa. REST resta ottimo, anzi spesso il punto di partenza consigliato, per le API pubbliche, il caso semplice, la facilità di tenere in scorta. GraphQL brilla sui dati complessi, i tanti clienti, le esigenze mutevoli. E le squadre mature, spesso, usano entrambi: GraphQL davanti, come fronte flessibile, con REST solido dietro. Non tifare per uno: riconosci la forma del tuo problema.
Voglio chiudere con la nota rassicurante, perché tocca un filo caro. E su un punto GraphQL è tranquillizzante, come lo erano stati altri prima. Anche se è nato dentro una grande azienda, oggi non le appartiene più: è una specifica aperta, affidata a una fondazione indipendente, che nessuna singola azienda possiede o può cambiarti a piacimento. Sulla domanda che ci accompagna da tante stagioni, chi possiede le tue opzioni, anche qui la risposta è serena: le possiede una comunità aperta, non un padrone solo. Puoi costruirci sopra senza il timore che qualcuno, un giorno, cambi le regole da sotto i piedi.
Per oggi ci fermiamo qui. La verità onesta: la libertà di GraphQL ha un prezzo. Primo, tenere le risposte in memoria di scorta, gratis in REST, qui diventa un lavoro complicato. Secondo, la complessità si sposta sul server, e la libertà data al cliente è un'arma carica, con richieste che possono essere rovinosamente costose: vanno messi dei limiti. Terzo, spessissimo è troppo: per un'API semplice, un REST basta e avanza. Conviene davvero solo con dati complessi, tanti clienti diversi, esigenze mutevoli, proprio la forma per cui è nato. La bussola è la solita: nessuno strumento è il migliore in assoluto, e spesso i due convivono. Con la nota serena che GraphQL è aperto, di una comunità, non di un padrone. Nella prossima e ultima puntata tiriamo le somme sul potere di chiedere bene. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.