GraphQL vs REST

Le API REST espongono le risorse a URL fissi, perciò una schermata che necessita dei dati di un utente, dei suoi post e dei commenti a quei post deve effettuare tre richieste HTTP sequenziali: GET /users/42, GET /users/42/posts, GET /posts/7/comments. Ogni risposta include tutti i campi definiti dal server, in genere 10-20 campi per oggetto anche quando il client ne richiede solo 3 o 4. Questo over-fetching si moltiplica sulle reti mobili e la struttura a cascata (ogni richiesta bloccata in attesa della risposta precedente) aggiunge latenza proporzionale al tempo di andata e ritorno, tipicamente 50-150 ms per hop su una connessione 4G.

GraphQL riduce le tre richieste a un singolo POST /graphql che trasporta una query tipizzata in cui sono nominati esattamente i campi necessari. Il livello dei resolver del server distribuisce la query verso le sorgenti dati in parallelo, restituendo un'unica risposta JSON strutturata. Il compromesso è che la cache HTTP GET (CDN e browser) non si applica più senza le Automatic Persisted Queries (APQ), poiché i corpi POST non vengono memorizzati nella cache per impostazione predefinita. Il problema N+1 si sposta dal client (richieste multiple) al server (chiamate al resolver per ogni elemento) e deve essere risolto con strumenti di batching come DataLoader di Facebook, che raggruppa N query DB individuali in un'unica chiamata con clausola IN. L'introspezione dei tipi, i contratti di schema fortemente tipizzati e le relazioni a grafo rendono GraphQL interessante per i team di prodotto con numerose superfici consumer, ma introducono un overhead di governance dello schema assente nelle API REST semplici.