Ciao, e benvenuto nell'ottava puntata della quarantaquattresima stagione. Nelle scorse puntate abbiamo montato tutto il meccanismo di GraphQL. Oggi saliamo dal meccanismo al mestiere, e parliamo di come si progetta bene un grafo, e di come lo si fa crescere nel tempo senza rompere niente. E qui c'è un bel contrasto con REST, perché GraphQL, grazie allo schema e alla penna in mano al cliente, offre un modo diverso, più gentile, di far evolvere un'API. Oggi vediamo uno schema che cresce.
Partiamo dal ricordare che un'API è un prodotto, perché vale anche qui. Come dicemmo per REST, anche un'API in GraphQL è un prodotto, e i suoi utenti sono altri programmatori, incluso te tra sei mesi. Quindi valgono le stesse virtù: empatia per chi la userà, coerenza, chiarezza. Ma la natura di GraphQL, tutta centrata sullo schema, dà alla progettazione un carattere particolare. Perché qui il cuore del lavoro è una cosa sola, ben precisa: disegnare bene il grafo.
Voglio darti il primo principio, pensare prima allo schema, perché è la vera arte. Siccome lo schema è il contratto, la mappa, la fonte di verità, progettare l'API significa, prima di tutto, progettare lo schema. Scegliere bene le cose e i loro nomi. Modellare fedelmente i collegamenti, così che il grafo rispecchi davvero come le cose stanno tra loro. Decidere quali campi offrire, e come chiamarli con chiarezza. In GraphQL, lo schema è il progetto: non è un dettaglio tecnico che viene dopo, è il disegno stesso dell'edificio. Il tempo speso a pensare bene lo schema è il tempo più prezioso di tutto il lavoro.
Voglio darti il contrasto con REST sul cambiare, perché è la novità più interessante. E qui viene la differenza affascinante. Ricordi come REST affrontava il problema di cambiare senza rompere? Spesso pubblicando versioni diverse, per aggiungere il nuovo senza spezzare chi si appoggiava al vecchio. GraphQL preferisce un'altra strada, più continua. Siccome il cliente chiede solo i campi che vuole, tu puoi aggiungere nuovi campi allo schema liberamente, senza rompere nessuno: chi non li conosce, semplicemente non li chiede, e non se ne accorge nemmeno. Il grafo cresce aggiungendo, senza disturbare chi c'era già.
Voglio completare l'idea con il ritirare con gentilezza, perché è l'altra metà. E i campi vecchi, quelli che non vuoi più? Non li tagli di netto. Li marchi come da non usare più, segnalando con gentilezza per favore, smetti di usare questo, mentre continuano a funzionare ancora per un po', per chi non ha ancora cambiato. Così nessuno si ritrova, da un giorno all'altro, con qualcosa che si rompe. Il grafo evolve di continuo, aggiungendo il nuovo e accompagnando fuori il vecchio con dolcezza, invece di saltare bruscamente da una versione all'altra. È una crescita fluida, resa possibile proprio dal fatto che è il cliente a scegliere i campi.
Voglio ricordare che la responsabilità resta, perché il meccanismo cambia ma il dovere no. Attenzione, questo non significa che tu possa fare quel che vuoi. La responsabilità di cui parlammo resta identica: altri dipendono dal tuo schema, quindi non puoi togliere le cose con leggerezza, non puoi tradire ciò su cui contano. Ciò che cambia non è il dovere di mantenere le promesse: è il modo di mantenerle. In REST si tende a versionare, a offrire un nuovo edizione accanto alla vecchia. In GraphQL si fa crescere e si accompagna fuori con gentilezza. Due modi diversi di onorare la stessa promessa: non rompere chi si fida di te.
Voglio darti l'immagine che rende chiara questa idea, e la lezione. Pensa alla differenza tra due modi di aggiornare un catalogo. Il primo: ogni anno pubblichi un'edizione nuova di zecca, e costringi tutti a passare a quella. Il secondo: tieni un unico catalogo vivo, a cui aggiungi i prodotti nuovi via via, e su cui segni i vecchi come non più disponibili, scegli pure il sostituto, così nessuno è mai costretto a reimparare tutto in un colpo. GraphQL somiglia al secondo. La lezione: spesso il modo migliore di tenere stabile un'interfaccia mentre cresce è farla evolvere di continuo, aggiungere con gentilezza, ritirare con gentilezza, invece di rompere e rifare. E quando il tuo progetto ruota attorno a un contratto esplicito, prendersi cura di quel contratto è, semplicemente, il mestiere.
Per oggi ci fermiamo qui. Siamo saliti al mestiere: come si progetta e si fa crescere un grafo. Anche in GraphQL un'API è un prodotto, ma tutto ruota attorno allo schema, e progettare bene significa prima di tutto disegnare bene il grafo: nomi chiari, collegamenti fedeli. E sul cambiare senza rompere, GraphQL offre una via più gentile di REST: siccome il cliente chiede solo ciò che vuole, puoi aggiungere campi nuovi senza disturbare nessuno, e ritirare i vecchi con delicatezza, marcandoli da non usare più invece di tagliarli. Il grafo cresce di continuo, invece di saltare tra versioni. La responsabilità resta la stessa: non tradire chi si fida; cambia solo il modo di onorarla. La lezione: far evolvere con gentilezza batte rompere e rifare. Nella prossima puntata affrontiamo il tema onesto: il prezzo della libertà. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.