Mito 1: gRPC é apenas para chamadas síncronas ultrarrápidas entre serviços

Veredito prático

Na prática, o gRPC oferece muito mais do que chamadas síncronas rápidas. Ele suporta diferentes padrões de comunicação, incluindo streaming unário, streaming de servidor, streaming de cliente e streaming bidirecional. Isso permite cenários como telemetria em tempo real, atualização de estado entre serviços e comunicação eficiente entre clientes e servidores com contratos fortemente tipados.

• Transporte via HTTP/2, com multiplexação de streams e compressão; múltiplas chamadas concorrentes podem coexistir em uma única conexão.
• Streaming facilita fluxos contínuos de dados sem reconsultar o servidor para cada mensagem.
• Modelagem de API com contratos estáveis e evolução controlada, o que favorece serviços internos com várias equipes.
• Não é a melhor escolha para APIs públicas expostas diretamente a navegadores sem adaptação (ver Mito 3).

Mito 2: Protobuf é rígido demais e não evolui bem

Verdade prática

Protobuf, utilizado por gRPC, é projetado para evoluir com segurança. Mudanças compatíveis são possíveis se você seguir as regras de numeração de campos, uso de campos opcionais e a gestão de depreciação. Em proto3, campos não usados podem ser marcados como opcionais e novos campos são adicionados sem quebrar clientes existentes, desde que ocorram de forma compatível com o contrato.

• Não renomeie nem reatribua números de campo já usados.
• Para mudanças não compatíveis, use novas mensagens/serviços e mantenha as antigas por tempo limitado.
• Utilize oneof e enum para evoluir esquemas com menor impacto.
• Planeje a evolução com testes de compatibilidade entre versões de clientes e serviços.

// Exemplo mínimo de proto3 com evolução segura
syntax = "proto3";

package mythgrcp;

service HelloService {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
  // Novo campo pode ser adicionado sem quebrar clientes existentes
  string locale = 2;
}

message HelloReply {
  string message = 1;
}

Mito 3: gRPC não funciona no navegador

Verdade prática

Conforme a prática atual, chamadas diretas gRPC não são suportadas nativamente em navegadores devido a limitações de CORS e ao protocolo HTTP/2 bruto. Existem abordagens como gRPC-Web, que utiliza um gateway/proxy para traduzir chamadas gRPC para um formato compatível com navegadores, mantendo o benefício dos contracts fortes no back-end.

• Para navegadores, opte por gRPC-Web ou por REST/JSON no frontend, conectando-se ao gateway que traduz o protocolo.
• Envoy e outros proxies podem atuar como ponte entre o cliente Web e serviços gRPC, garantindo autenticação, CORS e políticas de tráfego.
• Se precisar de streaming no frontend, use gRPC-Web streaming (quando suportado) ou combine com WebSocket em caminhos específicos, sempre com sua camada de gateway.

Mito 4: gRPC substitui REST em tudo

Verdade prática

gRPC é excelente para comunicação entre serviços internos, serviços com contratos fortes e casos de streaming. REST continua sendo a escolha natural para APIs públicas, interoperabilidade, depuração e anotações legíveis por humanos. Em uma arquitetura moderna, é comum combinar os dois: gRPC para serviço interno e REST/REST+JSON para o público e integrações com ferramentas legacy.

• Use gateways para expor APIs REST a partir de serviços gRPC quando necessário.
• Invista em observabilidade, documentação de contratos e versionamento bem planejado para ambos os estilos.
• Escolha o estilo com base no público, na necessidade de streaming e na facilidade de evolução do contrato.