gRPC em Kotlin: quando usar e como não errar

gRPC em Kotlin: quando usar para não se arrepender

Imagine: você está escrevendo microsserviços em Kotlin, tudo funciona, mas as requisições entre eles começam a ficar lentas. A API REST que você tanto amava começa a irritar — muita serialização, muito overhead HTTP. Você começa a pesquisar "maneira rápida de comunicação entre microsserviços" e encontra o gRPC. E imediatamente surge a pergunta: "Não é exagero? Talvez seja melhor deixar como está?"

Vamos analisar. gRPC em Kotlin não é apenas "mais um protocolo". É uma abordagem completamente diferente para a comunicação entre serviços. É mais rápido, mais rigoroso e mais poderoso que o REST, mas também mais complexo. Neste artigo, vou mostrar quando o gRPC é seu melhor amigo e quando é melhor usar o bom e velho REST. E, claro, vou mostrar código real em Kotlin.

O que é gRPC e por que é tão popular no mundo Kotlin?

gRPC é um framework de chamada de procedimento remoto (RPC) do Google. Ele usa Protocol Buffers (protobuf) para serialização de dados e HTTP/2 para transporte. Se REST é como enviar cartas pelo correio (cada requisição é uma carta separada), o gRPC é como uma conversa telefônica direta: rápida, bidirecional e com latência mínima.

Para desenvolvedores Kotlin, o gRPC é especialmente interessante porque:

• As corrotinas Kotlin se integram perfeitamente com streams assíncronos do gRPC.
• A tipagem forte do protobuf — menos erros em tempo de execução.
• Suporte a streaming bidirecional — ideal para chats, jogos e aplicações em tempo real.

Mas sejamos honestos: gRPC não é necessário em todos os lugares. E agora vou mostrar como saber se ele é necessário para o seu projeto.

Quando usar gRPC em Kotlin: 5 cenários infalíveis

1. Microsserviços com alta exigência de desempenho

Se seus microsserviços se comunicam com dezenas de milhares de requisições por segundo, o gRPC supera o REST em 2 a 5 vezes em velocidade. Tudo graças ao formato binário do protobuf e ao multiplexação do HTTP/2.

Exemplo: você tem um serviço de recomendações em Kotlin que precisa retornar conteúdo personalizado em milissegundos. REST com JSON seria "pesado" — cada requisição contém nomes de campos, colchetes e outros "lixos" textuais. O Protobuf transmite apenas números e strings sem encapsulamento desnecessário.

// Definição no arquivo .protoservice Recommender {    rpc GetRecommendations (UserRequest) returns (RecommendationsResponse);}

message UserRequest {    string user_id = 1;    int32 max_results = 2;}

message RecommendationsResponse {    repeated Item items = 1;}

O código no cliente Kotlin ficará conciso:

val stub = RecommenderGrpc.newBlockingStub(channel)val request = UserRequest.newBuilder()    .setUserId("user_123")    .setMaxResults(10)    .build()

val response = stub.getRecommendations(request)println("Recebidas ${response.itemsCount} recomendações")

2. Streaming de dados em tempo real

O gRPC suporta quatro tipos de streaming: servidor, cliente, bidirecional e unary simples. Em Kotlin, isso é especialmente conveniente com corrotinas — você pode transmitir dados como Flow.

Exemplo: um servidor de logs que envia novas entradas para o cliente em tempo real.

// Parte do servidor em Kotlinclass LogServiceImpl : LogServiceGrpcKt.LogServiceCoroutineImplBase() {    override fun streamLogs(request: LogRequest): Flow<LogEntry> = flow {        val logSource = getLogSource(request.logType)        logSource.collect { logEntry ->            emit(logEntry)        }    }}

// Parte do clienteval stub = LogServiceGrpcKt.LogServiceCoroutineStub(channel)stub.streamLogs(LogRequest.newBuilder().setLogType("error").build())    .collect { log ->        println("Novo log: ${log.message}")    }

Tente fazer o mesmo com REST e WebSocket — ficará complicado e lento.

3. Sistemas poliglotas