gRPC vs REST vs GraphQL: escolhendo o protocolo certo para cada caso

1. Fundamentos e contexto de cada protocolo

A escolha do protocolo de comunicação entre sistemas é uma das decisões arquiteturais mais críticas no desenvolvimento moderno. Três abordagens dominam o cenário atual: REST, GraphQL e gRPC, cada uma com princípios fundamentais distintos.

REST (Representational State Transfer) opera sobre princípios arquiteturais definidos por Roy Fielding: stateless, operações baseadas em recursos e uso de verbos HTTP (GET, POST, PUT, DELETE). O Richardson Maturity Model classifica APIs REST em níveis que vão desde "apenas um serviço HTTP" até "hypermedia controls" (HATEOAS). Exemplo de chamada REST:

GET /api/usuarios/123
Host: api.exemplo.com
Accept: application/json

Resposta:
{
  "id": 123,
  "nome": "Maria Silva",
  "email": "maria@exemplo.com",
  "dataCadastro": "2024-01-15"
}

GraphQL introduz consultas declarativas com schema fortemente tipado. O cliente especifica exatamente quais campos deseja, eliminando over-fetching. Exemplo:

query {
  usuario(id: 123) {
    nome
    email
    pedidos(limite: 5) {
      id
      total
      itens { nome }
    }
  }
}

gRPC utiliza Protocol Buffers como linguagem de definição de interface (IDL) e serialização binária, operando sobre HTTP/2. Suporta quatro tipos de streaming: unário, server-streaming, client-streaming e bidirecional.

// Arquivo .proto
service UsuarioService {
  rpc GetUsuario (UsuarioRequest) returns (UsuarioResponse);
  rpc ListarPedidosStream (PedidosRequest) returns (stream Pedido);
}

message UsuarioRequest {
  int32 id = 1;
}

message UsuarioResponse {
  int32 id = 1;
  string nome = 2;
  string email = 3;
}

2. Casos de uso ideais para REST

REST permanece a escolha padrão para APIs públicas devido à ampla compatibilidade com navegadores, dispositivos móveis e ferramentas de desenvolvimento. É ideal para operações CRUD simples e cenários que se beneficiam do cacheamento HTTP nativo (CDNs, proxies reversos).

Exemplo prático de API REST para catálogo de produtos:

GET /api/produtos?categoria=eletronicos&pagina=1&limite=20
Cache-Control: public, max-age=300

Resposta:
{
  "produtos": [
    {"id": 1, "nome": "Notebook", "preco": 4500.00},
    {"id": 2, "nome": "Mouse", "preco": 89.90}
  ],
  "total": 150,
  "pagina": 1
}

Limitações incluem over-fetching (receber dados não utilizados) e under-fetching (múltiplas requisições para dados relacionados), além da ausência de tipagem forte no payload.

3. Quando GraphQL se destaca

GraphQL brilha em aplicações com frontends complexos que exigem flexibilidade nas consultas. É particularmente eficaz como Backend for Frontend (BFF), permitindo que cada cliente (web, mobile, desktop) obtenha exatamente os dados necessários.

Exemplo de mutation GraphQL para checkout de e-commerce:

mutation {
  finalizarPedido(
    carrinhoId: "cart_789",
    enderecoEntrega: {rua: "Av. Paulista", numero: 1000}
  ) {
    pedidoId
    status
    total
    previsaoEntrega
  }
}

Desafios incluem caching granular (diferente do cache por URL do REST), complexidade de queries aninhadas que podem sobrecarregar o servidor, e segurança em nível de campo para autorização.

4. O poder do gRPC em microsserviços e sistemas de alta performance

gRPC é a escolha natural para comunicação service-to-service em arquiteturas de microsserviços, oferecendo baixa latência, tipagem forte e streaming eficiente. Protocol Buffers geram payloads até 6x menores que JSON equivalente.

Exemplo de streaming bidirecional para atualizações de inventário:

// Servidor gRPC
rpc AtualizarInventario (stream AtualizacaoRequest) returns (stream StatusResponse);

message AtualizacaoRequest {
  int32 produto_id = 1;
  int32 quantidade = 2;
  string tipo_operacao = 3; // "entrada" ou "saida"
}

message StatusResponse {
  bool sucesso = 1;
  int32 estoque_atual = 2;
  string timestamp = 3;
}

Trade-offs incluem suporte limitado em navegadores (necessitando gRPC-Web ou proxy), ferramental de debugging menos maduro que REST, e dependência de HTTP/2.

5. Comparação prática: desempenho, serialização e latência

Benchmarks típicos mostram diferenças significativas:

Característica REST (JSON) GraphQL gRPC (Protobuf)
Tamanho payload 100% (base) 70-90% 15-25%
Latência média 50-150ms 30-100ms 5-30ms
Throughput (req/s) 1000 800 5000+

A serialização binária do Protocol Buffers reduz drasticamente o tráfego de rede. gRPC também se beneficia do multiplexing do HTTP/2, permitindo múltiplas requisições simultâneas sem head-of-line blocking.

6. Decisão baseada em requisitos do projeto

Matriz de decisão prática:

  • Clientes web/mobile: REST (simplicidade) ou GraphQL (flexibilidade)
  • Microsserviços internos: gRPC (desempenho)
  • IoT/edge computing: gRPC (payloads compactos)
  • APIs públicas: REST (compatibilidade universal)

Exemplo de sistema de e-commerce híbrido:

// API Gateway configurando rotas
GET /api/catalogo/*     -> REST (cacheável, público)
POST /api/checkout/*    -> GraphQL (flexível, mobile)
gRPC internal:50051     -> gRPC (inventário, alta frequência)

7. Boas práticas de implementação e governança

Versionamento: REST usa URI (/v1/usuarios) ou cabeçalhos; GraphQL utiliza depreciação de campos com @deprecated; gRPC mantém compatibilidade adicionando campos opcionais aos .proto.

Monitoramento: métricas essenciais incluem latência por endpoint, taxa de erros (4xx, 5xx), e rastreamento distribuído com OpenTelemetry.

Segurança: autenticação via JWT (REST/GraphQL) ou mTLS (gRPC), rate limiting por chave de API, e validação rigorosa de schemas.

8. Tendências e futuro dos protocolos de API

A convergência com edge computing (Cloudflare Workers, Deno) favorece GraphQL e gRPC-Web para computação distribuída. GraphQL Subscriptions evoluem para cenários de tempo real, enquanto AsyncAPI e OpenAPI 3.1 buscam unificar documentação entre protocolos.

O ecossistema caminha para APIs híbridas, onde o mesmo serviço expõe interfaces REST para clientes externos, GraphQL para frontends e gRPC para comunicação interna, gerenciadas por API Gateways inteligentes.

Referências