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 round trip         (underfetching)
GET /users/42/followers     → terzo round trip

GraphQL parla con una sola domanda modellata:

POST /graphql
query {
  user(id: 42) {
    name
    avatarUrl
    posts(first: 5) { title likes }
    followers { totalCount }
  }
}
→ un solo round trip, 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’aggiunta a posteriori.

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 allowlist 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.