REST vs GraphQL vs gRPC — quando sceglieresti ciascuno?

Question

IT Interview Practice · Accepted Answer

Questi sono tre diversi paradigmi di API, ciascuno ottimizzato per vincoli diversi. Non c'è un vincitore universale — la scelta giusta dipende dal **consumatore, dalla forma dei dati e dalla rete**.

## I tre a colpo d'occhio

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

Orientato alle risorse su HTTP puro. **Sceglilo** per API pubbliche, servizi CRUD e qualsiasi cosa che benefici del caching HTTP, dell'ubiquità e della semplicità. I suoi punti deboli sono l'**over-fetching** (ottieni l'intero `/users/42` anche se ti serve un solo campo) e l'**under-fetching** (il problema `N+1`: recuperi un utente, poi cicli per recuperare ogni ordine).

```http
GET /users/42            → the whole user
GET /users/42/orders     → a second round trip
```

## GraphQL

Un singolo endpoint dove il **client specifica esattamente ciò che vuole** in una query, risolvendo l'over/under-fetching. **Sceglilo** per frontend ricchi (specialmente mobile, dove i round trip sono costosi) e quando molti client hanno bisogno di forme diverse degli stessi dati.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Compromessi: il caching HTTP è più difficile (tutto è un `POST` a `/graphql`), e un resolver ingenuo può nascondere costose query database `N+1`.

## gRPC

RPC contract-first che usa **Protobuf** su **HTTP/2**. Binario e multiplexato, quindi è veloce e compatto con supporto allo streaming. **Sceglilo** per la comunicazione **service-to-service interna** in un backend a microservizi dove performance e tipizzazione rigorosa contano. Punto debole: scarso supporto browser (serve un proxy come grpc-web) e non leggibile dall'uomo.

## Come scegliere

```text
Public API, CRUD, caching, wide reach   → REST
Complex/varied frontend data needs      → GraphQL
High-performance internal microservices → gRPC
(Real systems mix them: REST/GraphQL at the edge, gRPC between services.)
```

## Perché è importante

A livello senior, gli intervistatori si preoccupano meno delle definizioni e più del fatto che tu sappia **giustificare una scelta rispetto ai vincoli** — questa domanda è in realtà "sai abbinare una tecnologia a un problema invece di inseguire l'hype?". Le risposte più forti si ancorano al dolore che ciascuno risolve: GraphQL esiste per eliminare l'over/under-fetching per i frontend esigenti, gRPC esiste per rendere le chiamate ai servizi interni veloci e fortemente tipizzate, e REST resta il default perché il caching HTTP, il tooling e la familiarità universale sono enormi vantaggi pratici per le API pubbliche e in stile CRUD. Fondamentale, un ingegnere senior nota che **non è o l'uno o l'altro** — un'architettura comune è REST o GraphQL al bordo pubblico con gRPC tra i microservizi backend — e nomina i compromessi concreti (i rischi di caching e `N+1` di GraphQL, la debole storia browser di gRPC). È quel ragionamento su adeguatezza e costo, non la capacità di recitare funzionalità, il segnale.

I tre a colpo d'occhio

REST

GraphQL

gRPC

Come scegliere

Perché è importante

Domande correlate