gRPC em C#: quando REST é coisa do passado e HTTP/1.1 é um gargalo
\n\nImagine que você é um piloto de Fórmula 1. Seu carro é capaz de acelerar até 380 km/h, mas você está dirigindo no trânsito urbano. Sem sentido, certo? É mais ou menos assim que muitas pessoas usam gRPC em C# — uma ferramenta poderosíssima para comunicação entre serviços — em situações onde uma API REST comum seria suficiente. E depois se surpreendem: "por que é tão difícil depurar, por que tanto código?".
\n\nVamos entender quando usar gRPC é realmente justificado e quando é melhor ficar no confiável HTTP/1.1. Spoiler: gRPC não é uma bala de prata. É um acelerador de foguete para as tarefas certas.
\n\nO que é gRPC e por que C# é o terreno ideal
\n\ngRPC (Google Remote Procedure Call) é um framework para chamada remota de procedimentos, construído sobre HTTP/2 e Protocol Buffers. Em vez do pesado JSON, um formato binário compacto. Em vez de uma única requisição-resposta, streams completos, multiplexação e comunicação bidirecional.
\n\nPor que C# gRPC é tão bom? Porque o .NET Core foi projetado desde o início para microsserviços de alta carga. Assincronicidade, Span<T>, baixo nível de alocações — tudo isso torna a combinação C# + gRPC uma das mais performáticas da indústria.
\n\n// Exemplo de um arquivo .proto simples\nsyntax = "proto3";\n\nservice OrderService {\n rpc GetOrder (OrderRequest) returns (OrderResponse);\n rpc SubscribeOrders (OrderFilter) returns (stream OrderUpdate);\n}\n\nmessage OrderRequest {\n string order_id = 1;\n}\n\nmessage OrderResponse {\n string id = 1;\n double total = 2;\n repeated string items = 3;\n}\n\nApós a geração de código via protoc ou pacote Grpc.Tools, você obtém uma classe C# completa que pode ser usada como um método comum.
Quando o gRPC em C# é realmente necessário? 5 cenários de concreto armado
\n\n1. Microsserviços com alta carga (1000+ rps)
\n\nSe seu sistema processa milhares de requisições por segundo, cada kilobyte extra em JSON e cada RTT (round-trip time) adicional se transformam em perda de dinheiro. gRPC em C# oferece um ganho de velocidade de até 7 a 10 vezes em comparação com REST/JSON graças a:
\n\n- \n
- Serialização binária (Protobuf — 3 a 5 vezes mais compacto que JSON) \n
- Multiplexação HTTP/2 (um único canal TCP para múltiplas requisições) \n
- Ausência de custos extras com parsing de cabeçalhos \n
2. Streaming de dados em tempo real
\n\nPrecisa transmitir cotações de ações, logs, telemetria de sensores IoT ou atualizações de UI? Streaming gRPC C# é a sua escolha. Quatro tipos de streams são suportados:
\n\n- \n
- Unary — requisição-resposta clássica \n
- Server streaming — servidor envia dados para o cliente \n
- Client streaming — cliente envia um lote de dados para o servidor \n
- Bidirectional streaming — troca contínua bidirecional \n
// Parte do servidor para bidirectional streaming\npublic override async Task SubscribeOrders(\n IAsyncStreamReader<OrderFilter> requestStream,\n IServerStreamWriter<OrderUpdate> responseStream,\n ServerCallContext context)\n{\n await foreach (var filter in requestStream.ReadAllAsync())\n {\n var update = new OrderUpdate \n { \n OrderId = filter.OrderId, \n Status = "Shipped" \n };\n await responseStream.WriteAsync(update);\n }\n}\n\n3. Microsserviços internos de uma mesma equipe
\n\ngRPC não é adequado para APIs públicas (suporte fraco a navegadores, depuração complexa). Mas dentro de um cluster, é o transporte ideal. Se você controla tanto o cliente quanto o servidor, gRPC em C# oferece:
\n- \n
- Tipagem forte através de contratos .proto \n
- Geração automática de clientes \n
- Suporte a graceful shutdown e propagação de deadline