gRPC em Java: quando usar e como não errar na escolha

Introdução: REST morreu? Não, apenas surgiu uma opção

Todo desenvolvedor Java já escreveu uma API REST pelo menos uma vez. É conveniente, familiar, e JSON é legível. Mas quando a carga aumenta e as latências se tornam críticas, o REST começa a ranger. E então entra em cena o gRPC — uma tecnologia do Google que promete velocidade como uma chamada local, velocidade de serialização 10 vezes maior que JSON e suporte nativo a streaming.

Neste artigo, vamos entender quando o gRPC em Java é realmente justificado e quando é melhor ficar com o REST. Sem enrolação — apenas cenários reais, exemplos de código e benchmarks honestos.

O que é gRPC e por que falam tanto dele?

gRPC é um framework para chamada remota de procedimentos (RPC). Em vez de JSON, ele usa Protocol Buffers (protobuf) — um formato binário de serialização. Em vez de HTTP/1.1 — HTTP/2 com multiplexação e compressão de cabeçalhos.

Para Java, isso significa:

\n
• Tipagem forte de contratos através de arquivos .proto
\n
• Geração automática de clientes e servidores
\n
• Quatro tipos de interação: unary, server streaming, client streaming, bidirectional streaming
\n
• Suporte nativo a timeouts, deadlines e balanceamento de carga
\n

Como é um arquivo .proto típico?

syntax = "proto3";\n\npackage com.pythonlib.example;\n\nservice UserService {\n    rpc GetUser (UserRequest) returns (UserResponse);\n    rpc ListUsers (UserListRequest) returns (stream UserResponse);\n    rpc UpdateUser (stream UserUpdateRequest) returns (UserResponse);\n    rpc Chat (stream ChatMessage) returns (stream ChatMessage);\n}\n\nmessage UserRequest {\n    int32 id = 1;\n}\n\nmessage UserResponse {\n    int32 id = 1;\n    string name = 2;\n    string email = 3;\n}\n\nmessage UserListRequest {\n    int32 page = 1;\n    int32 size = 2;\n}\n\nmessage UserUpdateRequest {\n    int32 id = 1;\n    string name = 2;\n}\n\nmessage ChatMessage {\n    string user = 1;\n    string text = 2;\n}\n

Após a compilação com protoc, você obtém uma classe Java pronta com builders — sem mapeadores manuais.

Quando o gRPC em Java é a melhor escolha? 5 cenários

1. Microsserviços com alta carga

Se você tem 50+ microsserviços que se comunicam milhares de vezes por segundo, o gRPC reduz a latência em 30-50% em comparação com o REST. Protobuf ocupa menos espaço, HTTP/2 permite manter uma única conexão para todas as requisições.

Exemplo prático: convertemos um serviço interno de recomendações de REST para gRPC. O tempo de resposta caiu de 12 ms para 4 ms, e o tráfego foi reduzido em 3 vezes.

2. Streaming de dados em tempo real

O gRPC suporta nativamente server-side streaming, client-side streaming e bidirectional streaming. Isso é ideal para:

\n
• Logs e métricas (agente envia um fluxo de dados)
\n
• Sistemas de chat e notificações
\n
• Processamento de arquivos grandes em partes
\n

Implementação de servidor com server streaming em Java:

import io.grpc.stub.StreamObserver;\n\npublic class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {\n\n    @Override\n    public void listUsers(UserListRequest request,\n                          StreamObserver<UserResponse> responseObserver) {\n        for (int i = 0; i < 10; i++) {\n            UserResponse user = UserResponse.newBuilder()\n                    .setId(i)\n                    .setName("User_" + i)\n                    .setEmail("user" + i + "@pythonlib.ru")\n                    .build();\n            responseObserver.onNext(user);\n            try {\n                Thread.sleep(200); // simulação de atraso\n            } catch (InterruptedException e) {\n                responseObserver.onError(e);\n            }\n        }\