gRPC vs REST: o que muda de verdade quando você escolhe entre os dois

Você já esteve nessa reunião. Alguém acabou de voltar de uma palestra num evento e quer migrar toda a superfície de APIs internas para gRPC até sexta-feira. Ninguém perguntou que problema isso resolve. Só pareceu rápido.

Geralmente é assim que a adoção de gRPC começa, e é por isso que tantas dessas migrações empacam no meio do caminho, com uma mistura de serviços REST e gRPC que ninguém entende direito mais. O problema não é a ferramenta. É o jeito como a decisão é tomada.

Então vamos pular o discurso de marketing. O gRPC é bom de verdade em algumas coisas. Também é a escolha errada para boa parte dos serviços que você roda hoje, e fingir que não é assim é o caminho para acabar debugando um payload binário às 2 da manhã porque alguém não quis se dar ao trabalho de ver o que o curl retorna.

O que o gRPC te dá de verdade

A vantagem real do gRPC não é a velocidade naquele sentido abstrato que todo mundo repete. É um contrato estrito. Os Protocol Buffers obrigam você a definir a interface do serviço antes de escrever a implementação, e essa definição vale nas duas pontas. Se o tipo de um campo muda sem o bump de versão correspondente, o build quebra, em vez de um cliente interpretar errado um campo JSON, em silêncio, três meses depois.

Esse contrato importa mais num cenário específico: comunicação interna entre serviços, quando você controla as duas pontas e a superfície muda com frequência. Duas equipes fazendo deploy de forma independente, chamando uma à outra dezenas de vezes por request, ganham enormemente com um schema que não consegue divergir sem que alguém perceba em tempo de compilação.

O ganho de performance também é real, mas é menor do que o discurso sugere para a maioria das cargas de trabalho. O multiplexing do HTTP/2 e a serialização binária cortam latência real em chamadas de alto throughput e alta frequência entre serviços no mesmo data center. Se você faz doze chamadas por request entre serviços que estão a milissegundos de distância, isso se acumula. Se você faz uma chamada a cada poucos segundos para uma API downstream, não vai notar a diferença, e ainda colocou um formato de serialização que a pessoa de plantão precisa de uma ferramenta para ler.

O Protobuf também impõe uma disciplina que a maioria das equipes REST diz ter e raramente aplica: compatibilidade retroativa como restrição de primeira classe. Adicionar um campo é seguro. Remover ou renumerar um quebra todo cliente que ainda está no schema antigo, e o compilador deixa isso evidente antes de ir para produção. Equipes que já se queimaram com um cliente REST descartando em silêncio uma chave JSON renomeada costumam valorizar isso mais do que as que ainda não passaram por isso.

Onde o REST ainda ganha, e com folga

A vantagem real do REST é a legibilidade, não a simplicidade. Você abre uma API REST numa aba do navegador, cutuca com curl, lê a resposta e entende o que aconteceu sem ferramenta especial. A equipe de operações de plantão às 3 da manhã, debugando um incidente, não quer recorrer ao grpcurl e a um arquivo .proto para descobrir por que uma chamada downstream está devolvendo lixo. Ela quer ver o JSON.

Isso importa mais do que a maioria dos diagramas de arquitetura admite. O custo de um sistema não é só o que custa construí-lo. É o que custa operá-lo sob pressão, seis meses depois que a pessoa que o construiu foi para outra equipe. Poder inspecionar o REST é uma funcionalidade operacional, não uma limitação de legado.

O REST também ganha com folga em tudo que é público. Navegadores não falam gRPC nativamente. Quem integra de fora espera JSON sobre HTTP, porque toda linguagem e toda ferramenta lidam com isso sem trabalho extra. Se a sua API tem consumidores externos que você não controla, o gRPC adiciona uma camada de tradução (normalmente gRPC-Web mais um proxy) que resolve um problema que você não tinha até colocar gRPC.

Tem também um custo de contratação e onboarding que raramente entra nessas comparações. Um engenheiro novo consegue ser produtivo com uma API REST em uma hora, lendo a documentação e disparando requests pelo Postman. Deixar esse mesmo engenheiro produtivo com um serviço gRPC exige instalar as ferramentas certas, gerar client stubs a partir de arquivos .proto e entender um formato de serialização que ele provavelmente nunca usou fora desse trabalho. Esse tempo de adaptação é um custo real, e ele se acumula a cada contratação.

A decisão que ninguém quer tomar de forma explícita

Esta é a parte que a maioria do conteúdo sobre “gRPC vs REST” pula: a resposta honesta é que nenhum dos dois ganha sempre, e você provavelmente vai querer os dois, de propósito, não por acidente.

Um default útil para equipes que já passaram de certa escala: gRPC para chamadas internas entre serviços em que os dois lados são controlados pela sua organização e o throughput é alto. REST para tudo que é público, tudo que um navegador toca diretamente e tudo que uma equipe que não é de engenharia precisa cutucar durante um incidente.

O modo de falha não é escolher o errado. É escolher um e aplicar em todo lugar só por consistência. Consistência é um bom default até te custar observabilidade num endpoint voltado para o cliente, ou obrigar quem consome a sua API pública a brigar com a compilação de protobuf só para mandar um request.

Streaming é o argumento que esquecem de usar

Se a sua carga de trabalho realmente precisa de streaming bidirecional (pense em atualizações de posição ao vivo, chat ou telemetria contínua de uma frota de dispositivos), o suporte nativo do gRPC a streaming é um motivo legítimo para escolhê-lo em vez do REST, independentemente do argumento interno versus externo lá de cima. O REST consegue simular streaming com long polling ou server-sent events, mas os dois são gambiarras. Os streams HTTP/2 do gRPC foram feitos para isso desde o início, e se streaming é central no que você está construindo, só isso já pode definir a decisão.

Vale destacar porque é o único caso em que a escolha não passa de verdade por tráfego interno versus externo. Passa por saber se o seu modelo de dados é, no fundo, um stream ou, no fundo, um par request-response. A maioria dos serviços com cara de CRUD é a segunda opção. Alguns realmente não são.

Como isso fica numa migração real

Se você está migrando um serviço REST existente para gRPC por causa de um problema de latência específico e medido, faça isso só para esse serviço. Não deixe a mudança se espalhar por default para serviços que não têm o mesmo perfil de throughput.

Mantenha as definições .proto num repositório compartilhado, com ownership real e um processo de revisão, porque toda a proposta de valor desmorona no momento em que duas equipes definem tipos de mensagem sobrepostos de forma independente. Versione seus serviços de forma explícita. A rigidez do gRPC só é um ativo se alguém de fato fizer cumprir a disciplina de versionamento que ela exige.

Planeje a observabilidade antes da migração, não depois. Seus dashboards, a agregação de logs e o tracing que você já tem quase certamente foram montados em torno de status codes HTTP e payloads JSON. Os status codes do gRPC mapeiam de outro jeito, e payloads binários não aparecem numa linha de log como aparece um body REST. Equipes que pulam essa etapa acabam voando às cegas nas primeiras semanas depois do cutover, justo quando mais precisam enxergar o que mudou.

Também ajuda rodar os dois protocolos no mesmo serviço durante uma janela de transição, em vez de fazer o cutover num único deploy. Exponha um endpoint gRPC ao lado do REST que já existe, direcione uma pequena porcentagem do tráfego interno para ele e compare taxas de erro e latência diretamente antes de mover o resto dos seus clientes. Isso custa um pouco de manutenção extra por algumas semanas, mas sai mais barato do que fazer rollback de um serviço que conversa com uma dúzia de clientes que você nem sabia que existiam.

E registre, num lugar que a sua equipe vai realmente ler de novo, por que vocês fizeram a troca. Não por compliance. Porque daqui a dezoito meses alguém novo vai perguntar “por que temos dois paradigmas de API neste codebase”, e a resposta honesta precisa ser um motivo, não um dar de ombros.

Quando a resposta honesta é “ainda não”

Existe uma versão dessa decisão que vale para muitas equipes lendo uma comparação de gRPC pela primeira vez: você não tem o problema que o gRPC resolve. Se você roda quatro serviços com tráfego modesto e uma equipe pequena, o contrato que o gRPC oferece está resolvendo um problema de coordenação que você ainda não tem, porque todo mundo que mexe no codebase já sabe o que cada um construiu.

Isso muda quando você passa de certo número de serviços ou de certo número de equipes fazendo deploy de forma independente contra as APIs umas das outras. Não existe número mágico, mas o sinal é concreto: se você já teve um incidente em que uma equipe mudou o formato de uma resposta JSON e quebrou um cliente de que ninguém lembrava, você já encontrou o problema para o qual o contrato do gRPC foi feito. Se não teve, adotar gRPC agora é resolver uma hipótese, e você vai pagar o custo de ferramentas e onboarding por um benefício que ainda não consegue apontar.

No fim das contas

O gRPC não é o substituto moderno do REST. É uma ferramenta diferente, que troca a facilidade de inspeção por contrato estrito e throughput bruto, e essa troca vale a pena num conjunto de situações menor do que a maioria das palestras deixa transparecer. Os engenheiros que acertam nisso não são os que escolheram a opção que soava mais rápida. São os que conseguem te dizer exatamente qual problema cada protocolo da stack deles resolve, e por que o outro não servia para aquele caso específico.

Se você não consegue responder essa pergunta sobre os seus serviços agora, esse é o sinal de verdade. Não qual dos dois está mais na moda este ano.