gRPC e comunicação entre serviços: quando binário vence JSON

Quando dois serviços conversam milhares de vezes por segundo, o formato dessa conversa deixa de ser detalhe e vira custo. O JSON sobre HTTP que domina as APIs web é ótimo para muita coisa: legível, universal, fácil de depurar. Mas ele também é verboso, precisa ser convertido de texto para estrutura a cada mensagem, e carrega o peso do HTTP tradicional em cada chamada. Para a comunicação interna intensa entre microsserviços, esse custo se acumula, e é exatamente o problema que o gRPC foi criado para resolver, trocando texto por binário e ganhando velocidade onde ela mais importa.

Este guia explica o que torna o gRPC rápido, os tipos de streaming que ele oferece, como funcionam seus contratos e geração de código, e a pergunta honesta: quando o binário vence e quando o bom e velho REST continua sendo a melhor escolha. O foco é comunicação entre serviços, um tema distinto do design de APIs REST voltadas ao público e da organização da borda com gateways.

O que é gRPC

O gRPC é um framework de chamada de procedimento remoto (RPC) de alto desempenho. A ideia do RPC é fazer com que chamar um método em outro serviço, pela rede, se pareça o máximo possível com chamar uma função local: você invoca usuarioService.buscar(id) e o framework cuida de serializar os dados, enviar pela rede e devolver a resposta. Duas escolhas técnicas dão ao gRPC sua velocidade: o Protocol Buffers como formato e o HTTP/2 como transporte.

Protocol Buffers: binário e tipado

O coração do gRPC é o Protocol Buffers (protobuf), um formato de serialização binário e fortemente tipado. Em vez de transmitir texto como o JSON, o protobuf converte os dados em uma sequência compacta de bytes, guiada por um contrato definido de antemão.

Você descreve as mensagens e serviços em um arquivo .proto:

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

service UsuarioService {
  rpc Buscar(BuscarRequest) returns (Usuario);
}

As vantagens sobre o JSON são concretas:

• Menor. A representação binária é bem mais compacta que o texto equivalente, gastando menos banda.
• Mais rápida. Serializar e desserializar binário é mais rápido que converter texto de e para estrutura.
• Tipada por contrato. O .proto é a fonte da verdade. Os tipos são garantidos, e não descobertos em tempo de execução como num JSON solto.

HTTP/2: o transporte moderno

O gRPC roda sobre HTTP/2, e isso destrava recursos que o HTTP tradicional não tem. O mais importante é a multiplexação: várias chamadas trafegam ao mesmo tempo por uma única conexão, sem o gargalo de abrir conexões repetidas. Some a isso a compressão de cabeçalhos e o suporte nativo a fluxos bidirecionais, e você tem um transporte feito para comunicação intensa e contínua entre serviços, não para o modelo de uma requisição e uma resposta por conexão.

Os quatro tipos de streaming

Justamente por rodar sobre HTTP/2, o gRPC vai além do simples pergunta e resposta. Ele oferece quatro modos de comunicação, o que o torna muito mais flexível que uma API REST tradicional.

Tipo	Como funciona	Exemplo de uso
Unário	Uma requisição, uma resposta	Buscar um registro por id
Server streaming	Uma requisição, um fluxo de respostas	Acompanhar o progresso de um processo
Client streaming	Um fluxo de requisições, uma resposta	Enviar muitos dados em partes
Bidirecional	Fluxos nos dois sentidos ao mesmo tempo	Chat, sincronização em tempo real

O modo unário é o familiar, equivalente a uma chamada REST comum. Os modos de streaming são o diferencial: o servidor pode empurrar uma sequência de respostas, o cliente pode enviar dados em fluxo, ou os dois podem conversar ao mesmo tempo por um canal aberto. Isso abre casos que exigiriam soluções complicadas em REST.

Contratos e geração de código

Aqui está um dos maiores benefícios práticos do gRPC. Como o arquivo .proto é um contrato formal, uma ferramenta gera automaticamente o código de cliente e servidor a partir dele, em várias linguagens. O serviço em uma linguagem e o cliente em outra recebem, gerados, os tipos e as chamadas já prontos e coerentes com o contrato.

Isso elimina uma classe inteira de bugs. Não há mais divergência entre o que o servidor devolve e o que o cliente espera, porque ambos nascem da mesma definição. Mudou um campo no .proto? Regerar o código expõe na hora qualquer ponto que precisa se adaptar. O contrato deixa de ser uma documentação que envelhece e vira código verificado pela máquina.

A limitação no navegador: grpc-web

Se o gRPC é tão bom, por que ele não substituiu o JSON em todo lugar? A maior barreira é o navegador. Os browsers não expõem o controle fino de HTTP/2 que o gRPC precisa, então um cliente web não fala gRPC diretamente com o servidor. A ponte é o grpc-web, uma variante que funciona no navegador por meio de um proxy que traduz entre o que o browser consegue fazer e o gRPC pleno do lado do servidor.

Na prática, isso reforça o lugar natural do gRPC: ele brilha na comunicação entre serviços de backend, onde você controla os dois lados e a rede, e é menos direto na fronteira com o navegador, onde o REST e o JSON continuam mais simples de usar.

gRPC ou REST?

A decisão, como quase tudo em engenharia, é sobre encaixe, não sobre superioridade.

Critério	gRPC	REST com JSON
Formato	Binário (protobuf)	Texto (JSON)
Transporte	HTTP/2	Geralmente HTTP/1.1
Performance	Alta, compacta	Menor, verbosa
Streaming	Nativo, quatro modos	Limitado
Legibilidade humana	Baixa (binário)	Alta
Uso no navegador	Indireto (grpc-web)	Direto e simples
Melhor para	Comunicação interna entre serviços	APIs públicas e clientes web

O gRPC vence na comunicação interna de alto volume entre microsserviços, onde performance, streaming e contratos fortes pagam por si. O REST com JSON continua imbatível em APIs públicas, integrações com terceiros e clientes web, onde a legibilidade, a universalidade e a simplicidade importam mais que os microssegundos economizados. Muitos sistemas usam os dois: gRPC nas conversas internas entre serviços, e REST na fronteira exposta ao mundo.

O formato certo para a conversa certa

gRPC não é um REST melhor; é uma ferramenta afiada para um problema específico. Quando serviços internos conversam muito, o formato binário do protobuf, o transporte HTTP/2 e os contratos gerados por código entregam velocidade, eficiência e segurança de tipos que o JSON não alcança. Fora desse contexto, na fronteira pública e no navegador, o REST segue sendo a escolha mais simples e sábia. A maturidade está em saber que a mesma arquitetura pode falar as duas línguas: binário e eficiente por dentro, textual e universal na borda, cada um onde rende mais.

---

Seus serviços internos gastam tempo demais serializando e trafegando JSON? Na ConstructorTI, desenhamos a comunicação entre serviços com a tecnologia certa, gRPC onde performance e streaming importam, REST onde a simplicidade vence, sem dogma. Se a conversa interna do seu sistema virou gargalo, fale com a nossa engenharia e receba um diagnóstico da sua camada de comunicação.