REST vs GraphQL vs gRPC — quando você escolheria cada um?

Question

IT Interview Practice · Accepted Answer

Estes são três paradigmas de API diferentes, cada um otimizado para constraints diferentes. Não há um vencedor universal — a escolha certa depende do **consumidor, do formato dos dados, e da rede**.

## Os três num relance

```text
           REST                 GraphQL              gRPC
Estilo     resources + HTTP     um query graph       RPC (chama métodos)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binário)
Busca      endpoints fixos      client escolhe campos  métodos fixos
Schema     opcional (OpenAPI)   forte, tipado        forte, .proto
Browser    nativo, cacheável    precisa client lib   limitado (precisa proxy)
```

## REST

Orientado a recursos sobre HTTP puro. **Escolha-o** para APIs públicas, serviços CRUD, e qualquer coisa que se beneficie de HTTP caching, ubiquidade, e simplicidade. Suas fraquezas são o **over-fetching** (você recebe o `/users/42` inteiro mesmo que precise de um campo) e o **under-fetching** (o problema `N+1`: buscar um user, depois iterar para buscar cada order).

```http
GET /users/42            → o user inteiro
GET /users/42/orders     → um segundo round trip
```

## GraphQL

Um único endpoint onde o **client especifica exatamente o que quer** em uma query, resolvendo o over/under-fetching. **Escolha-o** para frontends ricos (especialmente mobile, onde os round trips são caros) e quando muitos clients precisam de formatos diferentes dos mesmos dados.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← um round trip, campos exatos
```
Trade-offs: o HTTP caching é mais difícil (tudo é um `POST` para `/graphql`), e um resolver ingênuo pode esconder queries `N+1` caras no banco de dados.

## gRPC

RPC contract-first usando **Protobuf** sobre **HTTP/2**. Binário e multiplexado, então é rápido e compacto com suporte a streaming. **Escolha-o** para comunicação **service-to-service interna** em um backend de microsserviços onde desempenho e tipagem estrita importam. Fraqueza: suporte fraco a browser (precisa de um proxy como grpc-web) e não é legível por humanos.

## Como escolher

```text
API pública, CRUD, caching, alcance amplo → REST
Necessidades de dados de frontend complexas/variadas → GraphQL
Microsserviços internos de alto desempenho → gRPC
(Sistemas reais os misturam: REST/GraphQL na borda, gRPC entre serviços.)
```

## Por que isso importa

No nível senior, os entrevistadores se importam menos com definições e mais com se você consegue **justificar uma escolha frente às constraints** — esta pergunta é na verdade "você consegue casar uma tecnologia com um problema em vez de perseguir o hype?". As respostas mais fortes se ancoram na dor que cada um resolve: o GraphQL existe para matar o over/under-fetching de frontends exigentes, o gRPC existe para tornar as chamadas de serviço internas rápidas e fortemente tipadas, e o REST continua o padrão porque HTTP caching, tooling, e a familiaridade universal são vantagens práticas enormes para APIs públicas e no estilo CRUD. Crucialmente, um engenheiro senior nota que **não é um ou outro** — uma arquitetura comum é REST ou GraphQL na borda pública com gRPC entre os microsserviços de backend — e nomeia os trade-offs concretos (os riscos de caching e `N+1` do GraphQL, a história fraca de browser do gRPC). É esse raciocínio sobre adequação e custo, não a capacidade de recitar features, que é o sinal.

Os três num relance

REST

GraphQL

gRPC

Como escolher

Por que isso importa

Perguntas relacionadas