Ciao, e benvenuto nella quinta puntata della quarantaquattresima stagione. Nelle scorse puntate abbiamo visto la penna in mano al cliente, il grafo, e lo schema che fa da mappa. Oggi guardiamo una differenza strutturale sorprendente rispetto a REST, e lo faccio apposta per contrasto, perché illumina una scelta di progettazione profonda. In REST il significato stava nell'indirizzo; in GraphQL c'è una sola porta, e il significato sta nella richiesta. Oggi capiamo l'endpoint unico, e dove abita il significato.
Partiamo da come faceva REST, perché il contrasto è tutto. Ricordi? In REST, il significato vive nell'indirizzo. Ogni cosa ha il suo indirizzo, e a quale indirizzo bussi dice cosa vuoi: bussare all'indirizzo degli utenti significa volere gli utenti, bussare a quello di un ordine significa volere quell'ordine. L'indirizzo, il luogo dove vai, porta con sé il significato della richiesta. Tante porte, ciascuna che dice, già dal suo nome, cosa troverai dietro.
Voglio mostrarti come fa GraphQL, perché sposta le cose. GraphQL fa il contrario: c'è una sola porta, un unico punto d'accesso, e bussi sempre lì, per qualunque cosa tu voglia. Non è più dove bussi a dire cosa vuoi: è cosa scrivi nella richiesta che porti con te. Ti presenti sempre alla stessa identica porta, e consegni il tuo foglietto d'ordine, che dice per intero cosa desideri. Il significato non è più nel luogo: è nel messaggio. Una porta sola, e una richiesta che parla per te.
Voglio spiegarti perché questo spostamento sia necessario, perché non è un capriccio. C'è una ragione precisa dietro. In REST chiedevi una cosa fissa a un indirizzo fisso, e allora aveva senso che ogni cosa fissa avesse il suo indirizzo. Ma in GraphQL tu non chiedi una cosa fissa: chiedi una forma qualunque del grafo, una combinazione su misura di cose e collegamenti, diversa ogni volta. Nessun indirizzo potrebbe mai dare un nome a tutte le forme possibili che potresti inventare. E allora il significato deve per forza spostarsi: dall'indirizzo, che non basta più, alla richiesta, che sola può descrivere la forma esatta che vuoi. È la conseguenza naturale di lasciare la penna al cliente.
Voglio essere onesto sul compromesso, perché ogni scelta ne ha uno. E qui devo dirti una cosa con franchezza, perché ci torneremo. Quegli indirizzi di REST non erano solo etichette: erano anche indovinabili, navigabili, e facili da tenere in memoria di scorta, perché un indirizzo fisso è facile da riconoscere e da riusare. Con una sola porta e richieste sempre diverse, dall'esterno non si capisce più, guardando dove bussi, cosa stai chiedendo: la porta è uniforme, ma opaca. Perdi qualcosa di ciò che rendeva REST comodo, in cambio della flessibilità. È un vero scambio, non un pasto gratis, e lo ritroveremo quando parleremo dei costi.
Voglio darti l'immagine che rende chiara questa idea, perché è netta. Pensa alla differenza tra due edifici. Nel primo, ogni stanza ha la sua porta con l'etichetta, e tu cammini fino alla porta giusta: il luogo dove arrivi ti dice già dove sei e cosa c'è. È REST. Nel secondo, c'è un unico bancone all'ingresso, un portiere, e tu gli consegni una richiesta scritta, e lui ti porta qualunque cosa, da qualunque parte dell'edificio. È GraphQL: una porta sola, ma è il tuo foglio a dire tutto. Nel primo, il significato è nel luogo; nel secondo, nel messaggio. Nessuno dei due è semplicemente migliore: distribuiscono il significato in modo diverso.
Voglio trarre la lezione generale, perché è sottile e preziosa. C'è una scelta di progettazione profonda, qui, che vale ovunque: dove far vivere il significato, nel luogo o nel messaggio? Metterlo nel luogo, come gli indirizzi di REST, ti dà indovinabilità e riuso, ma ti lega a cose fisse. Metterlo nel messaggio, come le richieste di GraphQL, ti dà libertà di forma, ma ti toglie ciò che il luogo fisso regalava. Non c'è una risposta giusta in assoluto: ogni scelta compra qualcosa e paga qualcos'altro. Riconoscere questo scambio, invece di credere che una via sia sempre migliore, è parte del saper scegliere bene.
Per oggi ci fermiamo qui. Abbiamo visto una differenza strutturale netta. In REST il significato sta nell'indirizzo: tante porte, e dove bussi dice cosa vuoi. In GraphQL c'è una sola porta, e il significato sta nella richiesta che porti: bussi sempre lì, e il tuo foglietto dice tutto. È necessario, perché non chiedi cose fisse ma forme qualunque del grafo, che nessun indirizzo potrebbe nominare. Con un compromesso onesto: perdi l'indovinabilità e la facilità di tenere in memoria che gli indirizzi fissi regalavano, un tema su cui torneremo. Come un edificio a stanze etichettate contro un unico bancone all'ingresso. La lezione: c'è una scelta profonda su dove vive il significato, nel luogo o nel messaggio, e ogni scelta compra e paga qualcosa. Nella prossima puntata vediamo cosa puoi fare: leggere, cambiare, restare in ascolto. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.