gRPC en Kotlin: cuándo usarlo y cómo no equivocarse

gRPC en Kotlin: cuándo usarlo para no arrepentirse

Imagine: está escribiendo microservicios en Kotlin, todo funciona, pero las solicitudes entre ellos se vuelven lentas. La API REST que tanto amaba comienza a molestarle: demasiada serialización, demasiada sobrecarga HTTP. Empieza a buscar en Google "forma rápida de comunicación entre microservicios" y se topa con gRPC. Y de inmediato surge la pregunta: "¿No será demasiado? ¿Quizás dejarlo como está?"

Vamos a analizarlo. gRPC en Kotlin no es solo "otro protocolo". Es un enfoque completamente diferente para la comunicación entre servicios. Es más rápido, más estricto y más potente que REST, pero también más complejo. En este artículo, le contaré cuándo gRPC es su mejor amigo y cuándo es mejor usar el viejo y confiable REST. Y, por supuesto, mostraré código real en Kotlin.

¿Qué es gRPC y por qué es tan popular en el mundo de Kotlin?

gRPC es un framework de llamada a procedimientos remotos (RPC) de Google. Utiliza Protocol Buffers (protobuf) para la serialización de datos y HTTP/2 para el transporte. Si REST es como enviar cartas por correo (cada solicitud es una carta separada), entonces gRPC es como una conversación telefónica directa: rápida, bidireccional y con latencias mínimas.

Para los desarrolladores de Kotlin, gRPC es especialmente interesante porque:

• Las corrutinas de Kotlin se combinan perfectamente con los streams asíncronos de gRPC.
• La tipificación estricta de protobuf reduce errores en tiempo de ejecución.
• El soporte para streaming bidireccional es ideal para chats, juegos y aplicaciones en tiempo real.

Pero seamos honestos: gRPC no es necesario en todas partes. Y ahora le mostraré cómo saber si es necesario para su proyecto.

Cuándo usar gRPC en Kotlin: 5 escenarios sólidos como una roca

1. Microservicios con altos requisitos de rendimiento

Si sus microservicios se comunican con decenas de miles de solicitudes por segundo, gRPC supera a REST en velocidad entre 2 y 5 veces. Todo gracias al formato binario de protobuf y la multiplexación de HTTP/2.

Ejemplo: tiene un servicio de recomendaciones en Kotlin que debe devolver contenido personalizado en milisegundos. REST con JSON sería "pesado": cada solicitud contiene nombres de campos, corchetes y otro texto basura. Protobuf transmite solo números y cadenas sin envoltorio innecesario.

// Definición en archivo .protoservice Recommender {    rpc GetRecommendations (UserRequest) returns (RecommendationsResponse);}

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

message RecommendationsResponse {    repeated Item items = 1;}

El código en el cliente Kotlin se verá conciso:

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

val response = stub.getRecommendations(request)println("Recibidas ${response.itemsCount} recomendaciones")

2. Streaming de datos en tiempo real

gRPC admite cuatro tipos de streaming: del servidor, del cliente, bidireccional y unario simple. En Kotlin, esto es especialmente conveniente con corrutinas: puede transmitir datos como un Flow.

Ejemplo: un servidor de logs que envía nuevas entradas al cliente en tiempo real.

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

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

Intente hacer lo mismo con REST y WebSocket: resultará engorroso y lento.

3. Sistemas políglotas