Quando un’azienda mi chiede di sviluppare una web app su misura, una delle prime decisioni tecniche che prendo riguarda le API: il livello che collega il frontend ai dati. La domanda ricorrente è sempre la stessa: REST o GraphQL? Sono due approcci diversi per costruire le interfacce di comunicazione di un’applicazione, e la scelta giusta dipende dal progetto, non dalla moda del momento. In questo articolo spiego come funzionano, quali problemi risolvono e con quali criteri decido nei progetti reali che costruisco e gestisco end-to-end.
Cos’è un’API e perché è il cuore della tua web app
Un’API (Application Programming Interface) è il punto di contatto tra l’interfaccia che l’utente vede e i dati che vivono nel database. Ogni volta che clicchi un pulsante, salvi un modulo o filtri un elenco, il browser invia una richiesta all’API, che risponde con i dati corretti. Un’API ben progettata rende la web app veloce, sicura e facile da far evolvere nel tempo. Un’API mal progettata, invece, diventa il collo di bottiglia che rallenta ogni nuova funzionalità. Per questo dedico tempo a scegliere l’architettura giusta fin dall’inizio.
REST: lo standard collaudato
REST è l’approccio più diffuso e maturo. Espone i dati attraverso una serie di “endpoint”, ciascuno corrispondente a una risorsa: ad esempio /clienti, /ordini, /fatture. Il frontend interroga l’endpoint che gli serve e riceve indietro i dati in formato JSON.
I vantaggi di REST sono concreti:
- Semplicità e prevedibilità: ogni risorsa ha un suo indirizzo chiaro, facile da documentare e da testare.
- Caching efficiente: le risposte si memorizzano facilmente a livello di browser, CDN o reverse proxy, migliorando le performance.
- Ecosistema enorme: strumenti, librerie e know-how sono ovunque, il che significa manutenzione più semplice e meno costosa nel tempo.
Il limite principale di REST emerge quando i dati sono molto correlati tra loro. Per comporre una schermata complessa il frontend a volte deve interrogare più endpoint (over-fetching e under-fetching): scarica più dati del necessario o, al contrario, deve fare richieste multiple. Su interfacce ricche e mobili questo può pesare.
GraphQL: una sola richiesta, i dati che ti servono
GraphQL ribalta l’approccio. Invece di tanti endpoint fissi, espone un unico punto di accesso a cui il frontend descrive esattamente quali dati vuole, e li riceve in un’unica risposta, senza eccessi né mancanze. È nato proprio per risolvere il problema dell’over-fetching su applicazioni con interfacce complesse e tanti dispositivi diversi da servire.
I punti di forza di GraphQL:
- Efficienza sui dati: una sola richiesta porta esattamente ciò che serve a una schermata, anche se i dati provengono da fonti diverse.
- Flessibilità per il frontend: il team che costruisce l’interfaccia può evolvere le viste senza dover modificare ogni volta il backend.
- Schema tipizzato e auto-documentante: il contratto tra frontend e backend è esplicito, riducendo gli errori e accelerando lo sviluppo.
In cambio, GraphQL aggiunge complessità: il caching è meno immediato che con REST, e serve attenzione su performance e sicurezza per evitare query troppo pesanti. Non è una soluzione “gratuita”: va gestita con competenza.
REST o GraphQL: come scelgo nei progetti reali
Non esiste un vincitore assoluto. Quando devo decidere tra REST e GraphQL valuto il progetto concreto, e in molti casi la risposta migliore è REST per la sua robustezza e semplicità di gestione. Ecco i criteri che applico:
- Scelgo REST quando le risorse sono ben definite, il caching è importante per le performance, l’app espone API a terze parti o serve un sistema gestionale classico con operazioni CRUD prevedibili.
- Scelgo GraphQL quando l’interfaccia è ricca e in rapida evoluzione, ci sono molti dati correlati da comporre in un’unica vista, o devo servire più client (web, mobile, dashboard) con esigenze di dati diverse.
- A volte li combino: REST per le integrazioni esterne e i flussi pubblici, GraphQL internamente per le interfacce più dinamiche. La pragmaticità conta più del dogma.
Il principio guida è sempre lo stesso: la tecnologia deve servire l’obiettivo dell’azienda, non il contrario. Una PMI che vuole digitalizzare un processo non ha bisogno della soluzione più alla moda, ma di quella più affidabile, manutenibile e adatta al suo budget.
Lo stack con cui costruisco le API
Costruisco e gestisco le mie web app dall’idea alla messa in produzione. Sul backend lavoro con Node.js e framework come Express o Fastify per le API REST, e con server GraphQL (in stile Apollo) quando il progetto lo richiede. Il frontend è in genere costruito con React e TypeScript, per interfacce moderne, veloci e tipizzate. Per la persistenza dei dati uso database relazionali come PostgreSQL e MySQL, con strati di caching come Redis dove le performance lo richiedono.
Sul fronte infrastruttura, ospito i progetti su server gestiti da me con HestiaCP, containerizzo i servizi con Docker e li orchestro tramite Portainer, configuro reverse proxy con Nginx e Apache e gestisco i certificati SSL per garantire connessioni cifrate. Questo controllo end-to-end è ciò che mi permette di garantire ai clienti applicazioni che non solo funzionano il giorno del lancio, ma restano sicure, aggiornate e performanti negli anni. Lo stesso approccio che applico alle mie applicazioni — da apicco.app a indelio.eu e tandemops.app — lo metto al servizio dei progetti dei miei clienti.
Vuoi una web app costruita bene? Parliamone
Scegliere tra REST e GraphQL è solo una delle tante decisioni che faccio per consegnare un prodotto solido. Se la tua azienda, in Italia o in Europa, ha bisogno di una web app su misura — un gestionale, un portale clienti, una dashboard o un’integrazione tra sistemi — posso seguirti dall’analisi iniziale fino alla manutenzione continua, con la responsabilità completa di un unico interlocutore.
Scopri i miei progetti su cornelcaba.com e contattami qui per raccontarmi la tua idea: trasformare un’esigenza aziendale in un’applicazione funzionante è esattamente il mio lavoro.
