gRPC: cos’è e quando usarlo al posto delle chiamate HTTP

Quando costruisci un’applicazione moderna, prima o poi due componenti devono parlarsi tra loro. La scelta più comune è una API REST che scambia JSON su HTTP. Funziona, è semplice e lo conoscono tutti. Ma esiste un’alternativa che negli ultimi anni è diventata lo standard de facto per la comunicazione tra microservizi: gRPC.

In questa guida ti spiego cos’è gRPC, come funziona, quali problemi risolve e, soprattutto, quando conviene usarlo al posto delle classiche chiamate HTTP. Senza fare il tifo per nessuna delle due tecnologie: ognuna ha il suo campo d’azione, e scegliere quella giusta fa la differenza tra un sistema che respira e uno che si trascina.

Cos’è gRPC

gRPC è un framework open source per chiamate di procedura remota (RPC, Remote Procedure Call), progettato inizialmente da Google e rilasciato nel 2015. Prima di gRPC, Google usava internamente un sistema simile chiamato Stubby: gRPC è la sua versione moderna, aperta a tutti e basata su standard pubblici.

L’idea dietro le RPC è semplice: il tuo codice chiama una funzione come se fosse locale, ma in realtà quella funzione viene eseguita su un altro server, magari dall’altra parte del mondo. È un concetto diverso da quello delle API REST, dove invece pensi in termini di risorse da leggere e modificare con GET, POST, PUT e DELETE.

Per capire gRPC devi conoscere i suoi due pilastri: Protocol Buffers (protobuf) e HTTP/2.

Come funziona gRPC

Il flusso di lavoro con gRPC è molto diverso da quello con REST:

• Definisci il servizio e i suoi messaggi in un file .proto, con tipi ben precisi per ogni campo.
• Compili il file con protoc: ottieni il codice del client e del server nel linguaggio che ti serve.
• Implementi il server con la logica vera, il client usa il codice generato per chiamarlo.
• I dati viaggiano in formato binario (protobuf), molto più compatto del JSON.
• La comunicazione avviene su HTTP/2, che permette multiplexing, compressione degli header e streaming bidirezionale.

Un dettaglio che sorprende molti: gRPC non sostituisce HTTP, ci viaggia sopra. Usa HTTP/2 come trasporto, quindi non stai abbandonando il web, stai usando un livello diverso dello stesso protocollo. Se ti interessa capire come funziona il vecchio HTTP a livello pratico, nella mia guida ai redirect 301 con file .htaccess trovi un esempio concreto di come si configura un server web classico.

I tipi di chiamata in gRPC

Rispetto al classico richiesta-risposta, gRPC offre quattro modelli di comunicazione:

• Unary: il client invia una richiesta, il server risponde una volta. È il modello equivalente a una chiamata HTTP classica.
• Server streaming: il client invia una richiesta, il server risponde con un flusso di messaggi. Perfetto per feed, notifiche, log in tempo reale.
• Client streaming: il client invia un flusso di messaggi, il server risponde una volta alla fine. Utile per caricare grandi quantità di dati.
• Bidirectional streaming: entrambe le parti inviano e ricevono messaggi in continuazione, in modo indipendente. È il modello ideale per chat e applicazioni real-time.

Quest’ultimo punto è quello che da solo giustifica la scelta di gRPC in molti progetti: con REST, uno streaming bidirezionale vero richiede WebSocket o soluzioni complicate, mentre con gRPC è una funzionalità nativa.

I vantaggi di gRPC

Perché un numero crescente di aziende lo sceglie per la comunicazione tra servizi?

• Performance superiori: il formato binario di protobuf è molto più compatto del JSON, e la serializzazione è più veloce. Su payload grandi e traffico intenso, la differenza si sente eccome.
• HTTP/2 multiplexing: più chiamate viaggiano in parallelo sulla stessa connessione, senza il problema del head-of-line blocking dell’HTTP/1.1.
• Contratti forti: il file .proto è un contratto formale tra client e server. Se un campo cambia, il compilatore te lo dice subito, prima che il bug arrivi in produzione. È lo stesso principio che sta dietro a standard come MCP, dove il contratto tra sistemi è esplicito e condiviso.
• Code generation: client e server nascono dal file di definizione, quindi il codice è sempre allineato al contratto, in qualsiasi linguaggio.
• Streaming nativo: i quattro modelli di chiamata coprono scenari che con REST richiedono accrocchi.
• Deadline e cancellation: ogni chiamata può avere un timeout, e il client può annullarla propagando la cancellazione al server. Gestire i tempi di risposta diventa molto più pulito.

I limiti di gRPC

Non è tutto oro. gRPC ha costi che devi conoscere prima di sceglierlo:

• Non è leggibile a occhio: il payload binario è illeggibile senza strumenti. Con REST apri il browser e vedi il JSON, con gRPC devi usare strumenti come grpcurl o la reflection.
• Browser ostile: i browser non possono parlare gRPC direttamente. Serve gRPC-Web, un adattatore con funzionalità ridotte, oppure un proxy.
• Debugging più complesso: niente più ispezione diretta della richiesta con curl. Servono strumenti specifici e una curva di apprendimento.
• Caching complicato: HTTP/2 e payload binari rendono il caching a livello HTTP molto più difficile che con REST, dove gli header di cache funzionano benissimo.
• Tooling meno maturo: l’ecosistema è cresciuto tanto, ma non è ancora al livello di quello REST in termini di proxy, firewall e strumenti di testing.

gRPC o HTTP REST: come scegliere

La domanda che tutti si fanno. La risposta onesta è: dipende dal contesto, ed ecco le linee guida che uso nella pratica.

Quando scegliere gRPC

• Comunicazione tra microservizi: è il caso d’uso per eccellenza. I servizi interni parlano tra loro con volumi alti, e la latenza conta.
• Streaming in tempo reale: chat, telemetria, aggiornamenti di prezzo, log in streaming: gRPC li gestisce in modo nativo.
• Payload grandi e frequenti: più i dati sono corposi, più il formato binario fa risparmiare banda.
• Team poliglotti: se i vari servizi sono scritti in linguaggi diversi, la code generation da un unico file .proto tiene tutto allineato.
• Sistemi con contratti rigidi: quando l’API deve essere tipizzata e versionata con precisione, protobuf è un alleato potente.

Quando restare su HTTP REST

• API pubbliche: se l’API è esposta a terzi, a clienti o al mondo esterno, REST con JSON è il linguaggio universale. Tutti sanno usarlo, tutti hanno gli strumenti per testarlo.
• Applicazioni web e mobile leggere: se il client è un browser, gRPC-Web aggiunge complessità senza grandi benefici.
• CRUD semplice: se devi solo creare, leggere, aggiornare e cancellare risorse, REST è perfetto e molto più diretto.
• Necessità di caching: se la tua API ha bisogno di caching aggressivo con CDN, REST vince senza discussioni.
• Team piccolo o inesperto: la curva di apprendimento di gRPC non è trascurabile. Se il team non la conosce, REST porta a casa il risultato con meno rischi.

Un esempio concreto: il file .proto

Per capire quanto sia diverso lavorare con gRPC, guarda quanto è pulito definire un servizio. Questo è un esempio minimale di un servizio di notifiche:

syntax = "proto3";

service NotificationService {
  rpc Send (NotificationRequest) returns (NotificationResponse);
  rpc Subscribe (stream SubscriptionRequest) returns (stream Notification);
}

message NotificationRequest {
  string user_id = 1;
  string message = 2;
}

Da questo file, protoc genera client e server in tutti i linguaggi supportati. La parte interessante è la seconda riga del servizio: con stream su entrambi i lati stai definendo una comunicazione bidirezionale in tempo reale. Con REST, per ottenere lo stesso risultato dovresti progettare WebSocket, gestire connessioni, riconnessioni e stato: con gRPC è una riga nel contratto.

Le alternative moderne

gRPC e REST non sono le uniche opzioni, e vale la pena sapere cosa c’è in giro:

• Connect RPC: un framework che unisce il meglio dei due mondi: definisci tutto con protobuf e ottieni sia endpoint gRPC sia endpoint REST compatibili con i browser.
• tRPC: molto amato nell’ecosistema TypeScript: la tipizzazione viaggia automaticamente tra client e server, senza file di definizione separati.
• GraphQL: la scelta giusta quando il problema è il client che deve ricevere esattamente i dati che vuole, niente di più e niente di meno.

Ognuna di queste risolve un problema specifico. Il punto non è quale sia la migliore in assoluto, ma quale si adatta meglio al tuo caso.

Domande frequenti su gRPC

gRPC è più veloce di REST?

Nella maggior parte dei casi sì, soprattutto con payload grandi e traffico intenso. Il formato binario, la serializzazione veloce e il multiplexing di HTTP/2 danno a gRPC un vantaggio misurabile. Su chiamate piccole e rare, la differenza è trascurabile.

gRPC funziona nel browser?

Non direttamente. I browser supportano HTTP/2 ma non le chiamate gRPC native, quindi serve gRPC-Web, che però non supporta tutte le funzionalità (per esempio lo streaming bidirezionale vero). Per questo spesso si usa gRPC tra i servizi e REST verso il browser.

gRPC sostituisce HTTP?

No, anzi: gRPC usa HTTP/2 come trasporto. Non abbandoni il web, usi un livello più efficiente dello stesso protocollo.

Quando non conviene usare gRPC?

Quando l’API è pubblica, quando il client principale è il browser, quando ti serve un caching semplice con CDN o quando il team non ha esperienza con protobuf. In questi casi REST con JSON è la scelta più pragmatica.

gRPC è adatto a un progetto piccolo?

Se il progetto è un’app monolitica con poche chiamate, gRPC aggiunge complessità senza benefici concreti. Diventa interessante quando il sistema cresce, i servizi si moltiplicano e le performance contano.