GraphQL vs. REST: quale stile di API, e quando?

REST è uno stile di API con molti endpoint fissi; GraphQL è un linguaggio di query in cui il client chiede a un solo endpoint i campi che gli servono. Il confronto riguarda in realtà chi decide la forma della risposta: in REST l’ha decisa il server in fase di progettazione; in GraphQL la decide il client a ogni richiesta. Tutto il resto – cache, versionamento, errori, prestazioni – discende da quella singola inversione.

Punti chiave

La stessa schermata, nei due modi

Una schermata di profilo ha bisogno di un utente, dei suoi cinque post più recenti e del numero di follower. REST parla per risorse:

GET /users/42               → 38 campi, ne servivano 3   (overfetching)
GET /users/42/posts?limit=5 → secondo giro               (underfetching)
GET /users/42/followers     → terzo giro

GraphQL parla con una sola domanda modellata:

POST /graphql
query {
  user(id: 42) {
    name
    avatarUrl
    posts(first: 5) { title likes }
    followers { totalCount }
  }
}
→ una sola andata e ritorno, esattamente quei campi, nient'altro

Il divario si restringe più di quanto suggeriscano i titoloni: anche un REST ben progettato supporta la selezione dei campi – e i query builder degli SDK la rendono un’abitudine di prima classe:

// JavaScript / Node.js — Back4app JS SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
const query = new Parse.Query('Article');
query.equalTo('status', 'published');
query.select('title', 'views');        // field selection, GraphQL-style
const articles = await query.find();   // lean payload over the REST API
// The same backend also speaks real GraphQL: query { articles { ... } }

// Flutter / Dart — Back4app Flutter SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
final query = QueryBuilder<ParseObject>(ParseObject('Article'))
  ..whereEqualTo('status', 'published')
  ..keysToReturn(['title', 'views']);   // field selection, GraphQL-style
final response = await query.query();   // lean payload over the REST API

// iOS / Swift — Back4app Swift SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
let query = Article.query("status" == "published")
  .select("title", "views")             // field selection, GraphQL-style
query.find { result in
  if case .success(let articles) = result { render(articles) }
}

// Android / Kotlin — Back4app Android SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
val query = ParseQuery.getQuery<ParseObject>("Article")
query.whereEqualTo("status", "published")
query.selectKeys(listOf("title", "views"))  // field selection, GraphQL-style
query.findInBackground { articles, e -> if (e == null) render(articles) }

GraphQL vs. REST a colpo d’occhio

Le parti che le pagine di confronto saltano

Il problema N+1 ha cambiato indirizzo, non è morto. Una query GraphQL per post-con-autori fa scattare ingenuamente una chiamata di resolver per ogni post – la stessa patologia N+1 che gli ORM hanno reso celebre, ora lato server. La cura standard è il batching: un loader per richiesta raccoglie gli identificatori degli autori e li recupera con una sola query. Adottare GraphQL senza una strategia di batching significa adottare il peggior bug prestazionale di REST a un nuovo indirizzo.

Gli errori sono una decisione operativa. “200 con un array errors” significa che dashboard, alerting e logica CDN costruiti sui codici di stato diventano ciechi per impostazione predefinita. I team che prosperano con GraphQL trattano l’osservabilità degli errori come parte dell’adozione, non come un pensiero successivo.

Le query senza limiti hanno bisogno di limiti. Un solo endpoint flessibile significa che una singola query può attraversare l’intero grafo – le indicazioni ufficiali di sicurezza parlano di limiti di profondità, budget sul costo delle query e liste di autorizzazione di persisted query per i client interni. Gli endpoint fissi di REST rendevano implicito il controllo dei costi; GraphQL lo lascia in mano a chi sviluppa.

Casi d’uso tipici

• GraphQL: app mobile su reti lente, dashboard che cuciono insieme molte entità, prodotti con client web + mobile + partner dai bisogni di dati divergenti, iterazione rapida del frontend contro uno schema stabile.
• REST: API pubbliche per sviluppatori, distribuzione di contenuti cacheabili, superfici di webhook e integrazione, trasferimento di file, chiamate fra servizi dove vince la semplicità.
• Entrambi (la norma enterprise): REST o RPC fra i servizi di backend; un livello GraphQL che li aggrega per i frontend – il pattern backend-for-frontend con uno schema.

Conviene scegliere GraphQL o REST? Matrice decisionale

Il punto di partenza onesto: conviene iniziare con REST e aggiungere GraphQL quando il dolore della modellazione dei dati per client eterogenei arriva davvero – e se la piattaforma genera entrambi da un solo schema, la scelta smette di essere architetturale e diventa una decisione per singola richiesta.

Limiti e trade-off

• REST: over/underfetching sulle schermate dense di dati, migrazioni di versione, deriva della forma delle risposte fra i team e N endpoint di documentazione.
• GraphQL: la cache richiede meccanismi, il controllo dei costi richiede vigilanza, i resolver richiedono disciplina di batching e il pattern 200-con-errors richiede di rifare l’osservabilità.
• Entrambi: nessuno dei due ripara un modello di dati sbagliato – un dominio confuso produce un’API confusa in qualunque stile, come la tesi stessa su REST lascia intendere con discrezione: i vincoli hanno sempre riguardato l’architettura sottostante.

GraphQL e REST su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Il dilemma di questo articolo si dissolve alla radice: entrambi gli stili di API sono generati dallo stesso schema – endpoint REST cacheabili per URL e un’API GraphQL tipizzata con query annidate – più gli SDK la cui selezione dei campi (le schede di codice qui sopra) consegna il beneficio di punta di GraphQL su entrambi i trasporti. Si sceglie per client, si cambia per schermata, e il livello di API non va scritto affatto.