REST vs GraphQL: Quale Scegliere per un Progetto Su Misura

Dietro ogni applicazione web moderna, dashboard aziendale o e-commerce, c’è un’API (Application Programming Interface) che fa da ponte tra il database e l’interfaccia utente. Da oltre due decenni, lo standard indiscusso per costruire questo ponte è stato REST. Negli ultimi anni, tuttavia, GraphQL (creato da Facebook) ha scosso il settore, promettendo di risolvere molti dei limiti storici di REST.

Il risultato? Molti team scelgono GraphQL semplicemente per seguire la moda (il famigerato Hype Driven Development), finendo per complicare inutilmente progetti che richiedevano soluzioni semplici - lo stesso rischio che racconto anche a proposito del Vibe Coding e dei suoi limiti: la tecnologia giusta è quella che serve al problema, non quella di cui si parla di più.

Per costruire software su misura che duri nel tempo, la scelta dell’architettura deve essere puramente pragmatica. Analizziamo i vantaggi reali di entrambi gli approcci e i criteri per scegliere quello giusto.

REST: L’Affidabilità dello Standard

Un’architettura REST (Representational State Transfer) si basa su concetti semplici e universali: utilizzi URL specifici (chiamati endpoint) per accedere a determinate risorse (es. /api/utenti/123) e usi i verbi HTTP standard (GET, POST, PUT, DELETE) per dirgli cosa fare.

I veri vantaggi di REST:

• Caching nativo: È il suo superpotere. Poiché ogni risorsa ha un proprio URL univoco e le richieste GET sono cacheable per impostazione predefinita, browser e CDN (come Cloudflare o Netlify) possono memorizzare le risposte sfruttando gli header HTTP standard (Cache-Control, ETag), alleggerendo drasticamente il carico sul server - lo stesso principio che sfrutto quando distribuisco un sito su una rete Edge/CDN per abbattere il TTFB.
• Semplicità universale: Qualsiasi sviluppatore, da un Junior a un Senior, sa come interrogare un’API REST. Non richiede librerie speciali lato client; basta una semplice fetch().

I limiti principali:

• Over-fetching: Se hai bisogno solo del “Nome” di un utente, l’endpoint REST ti restituirà comunque l’intero oggetto (nome, cognome, email, data di nascita, storico ordini). Scarichi dati inutili, sprecando banda preziosa (particolarmente critico su reti mobili) - un costo che si somma a quanto racconto in come la velocità del sito influenza le vendite.
• Under-fetching: Per mostrare una dashboard complessa, potresti dover fare 5 o 6 chiamate HTTP separate a endpoint diversi (es. /utenti, poi /ordini, poi /fatture), rallentando il rendering della pagina.

GraphQL: La Flessibilità su Misura

GraphQL capovolge il paradigma. Invece di avere decine di endpoint, hai un solo e unico endpoint (es. /graphql). Il client invia una Query strutturata chiedendo esattamente i campi di cui ha bisogno, e il server restituisce un JSON con la stessa identica struttura.

Ecco lo stesso scenario - una dashboard che mostra i dati di un utente, i suoi ordini e le sue fatture - nei due approcci:

// REST: 3 chiamate separate (e ogni risposta contiene anche campi che non useremo)
const [utente, ordini, fatture] = await Promise.all([
  fetch('/api/utenti/123').then((r) => r.json()),
  fetch('/api/utenti/123/ordini').then((r) => r.json()),
  fetch('/api/utenti/123/fatture').then((r) => r.json()),
]);

# GraphQL: 1 sola richiesta, solo i campi necessari
query {
  utente(id: 123) {
    nome
    ordini { id totale }
    fatture { numero importo }
  }
}

I veri vantaggi di GraphQL:

• Nessun over-fetching: Chiedi 3 campi, ricevi 3 campi. Questo rende le applicazioni client-side molto più veloci e leggere.
• Agilità del Frontend: I team frontend non devono più chiedere al backend di creare un nuovo endpoint ogni volta che il design della pagina cambia. Possono semplicemente modificare la query per richiedere dati diversi.
• Tipizzazione forte: GraphQL utilizza uno schema rigoroso (Schema Definition Language). Il client sa sempre esattamente quali dati sono disponibili e di che tipo (String, Int, Boolean) sono, riducendo drasticamente gli errori di comunicazione - un vantaggio che si sposa naturalmente con l’approccio che descrivo nel mio articolo su TypeScript e codice scalabile.

I limiti principali:

• Caching più complesso: Le query GraphQL viaggiano di norma via POST verso un solo endpoint, quindi la cache HTTP nativa di browser e CDN è molto meno efficace che con REST. Per compensare si ricorre a tecniche come le persisted queries o alla cache normalizzata lato client, tipicamente tramite librerie come Apollo Client o Relay.
• Il problema “N+1”: Se non configurato da mani esperte (ad esempio utilizzando i DataLoader), GraphQL può inavvertitamente interrogare il database centinaia di volte per una singola query, mettendo in ginocchio il server.

Criteri Pratici per la Scelta

Non esiste un vincitore assoluto. Quando mi siedo con un cliente per progettare l’architettura di un nuovo applicativo, utilizzo questi criteri decisionali - sempre prima di scrivere codice, come spiego nelle fasi di sviluppo di un progetto software aziendale.

Scegli REST se:

• Stai costruendo un’applicazione semplice o un MVP (Minimum Viable Product).
• La natura dei tuoi dati richiede un forte caching HTTP (es. un catalogo prodotti pubblico o articoli di un blog).
• Hai un budget limitato per l’infrastruttura iniziale e vuoi massimizzare la velocità di rilascio senza introdurre curve di apprendimento ripide.
• Devi interfacciarti con sistemi legacy o servizi di terze parti che si aspettano webhooks e chiamate HTTP tradizionali.

Scegli GraphQL se:

• Stai sviluppando un’applicazione altamente interattiva (come un social network, uno strumento di project management o una dashboard analitica) dove diverse entità sono fortemente interconnesse.
• L’applicazione verrà fruita massicciamente da dispositivi mobili su reti lente, dove il risparmio di banda e la minimizzazione delle richieste HTTP sono cruciali.
• Hai più client (Web, iOS, Android, Smartwatch) che necessitano di viste completamente diverse degli stessi dati.

E in un sito Astro? L’esempio di questo stesso sito

Per non restare sul teorico, ecco cosa uso davvero su questo sito - e cosa non uso:

• Nessun GraphQL, e nessuna API a runtime per il blog. Gli articoli sono file Markdown letti a build-time tramite le Content Collections di Astro: il sito è interamente statico, quindi non c’è alcun server o database da interrogare a ogni visita. Sforzare GraphQL qui sarebbe esattamente l’esercizio di stile di cui parlavo all’inizio.
• Un endpoint JSON REST-style con caching HTTP: /llms-full.json, la base di conoscenza in formato machine-readable pensata per crawler e agenti IA. Viene generato una sola volta in fase di build e servito con Cache-Control: public, max-age=86400 e CORS aperto (Access-Control-Allow-Origin: *). Un dettaglio pratico: Astro scarta gli header personalizzati sugli endpoint pre-renderizzati, per cui vanno dichiarati a livello CDN, nel netlify.toml - è proprio il caching HTTP nativo di cui parlavo nella sezione su REST, che qui lavora a costo zero.
• Una chiamata POST semplice per il form contatti: un normale fetch("/", { method: "POST", ... }) verso Netlify Forms, senza librerie né client dedicati.

Tre esempi reali, tre soluzioni minimali: per un progetto con queste esigenze, la soluzione più semplice possibile è anche quella giusta.

Conclusione

La tecnologia migliore è sempre e solo quella che risolve il problema di business nel modo più efficiente. Sforzare GraphQL in un blog statico è un inutile esercizio di stile, così come usare REST per una dashboard finanziaria in tempo reale rischia di creare un collo di bottiglia insostenibile. Analizzare a fondo la struttura dei dati e il comportamento atteso degli utenti prima di scrivere la prima riga di codice è l’unico modo per garantire che il tuo investimento software scali senza ostacoli - la stessa filosofia che guida la scelta tra un sito su misura e un CMS come WordPress.