gRPC: qué es, cómo funciona y cuándo usarlo (con ejemplos)

¿Qué es gRPC?

Si tuviera que explicarlo en dos minutos: gRPC es un framework de RPC moderno que usa HTTP/2 como transporte y Protocol Buffers (Protobuf) como formato binario por defecto. En vez de diseñar endpoints “resource-oriented” como en REST, defines servicios y métodos en un .proto, generas stubs de cliente/servidor y te hablas por contratos fuertemente tipados.

Lo que me gusta de este enfoque:

• Tipado fuerte y contratos versionables: evitan “drift” entre equipos.

• Eficiencia: multiplexación HTTP/2 + payload binario reducen latencia y ancho de banda.

• Streaming real: unary, server-streaming, client-streaming y bidirectional.

• Multi-lenguaje: generas clientes en Go, Java, .NET, Node, Python, etc.

En mi experiencia, este modelo brilla en microservicios donde la baja latencia y la consistencia de contratos importan más que la compatibilidad universal del navegador.

gRPC vs REST (y GraphQL): ventajas, límites y decisiones

Ventajas típicas de gRPC

• Menos latencia y menor peso: HTTP/2 (cabeceras comprimidas, multiplexación) + binario.

• Ergonomía para backends: contratos .proto claros, errores con códigos gRPC y deadlines.

• Streaming bidireccional sencillo: ideal para colas ligeras, feeds, telemetría.

Cuándo prefiero REST o GraphQL

• APIs públicas/para navegadores: compatibilidad y cachés/CDN listos.

• Exploración de datos flexible: GraphQL brilla cuando el cliente decide la forma del payload.

• Integraciones legacy: si tus consumidores no hablan gRPC, no fuerces la máquina.

Regla práctica que me funciona

• Interno, performance-sensible, contratos estables → gRPC.

• Externo, alto alcance, SEO/caché/CDN → REST.

• Fronts con necesidades dinámicas → suma GraphQL, y deja gRPC para el service mesh.

En un proyecto de microservicios en Kubernetes migré endpoints críticos a gRPC y la p95 bajó aproximadamente de 120 ms a 40 ms al pasar a Protobuf y usar streaming donde tocaba. No es magia: se gana por menos round-trips y payloads más compactos.

Cómo funciona gRPC por dentro

Stubs, .proto y generación
Defino contratos así:

Con ese contrato genero servidor y cliente. En Node, por ejemplo, activo deadlines y manejo códigos:

Tipos de llamadas

• Unary: request/response “clásico”.

• Server-streaming: el servidor envía una secuencia (progreso, logs).

• Client-streaming: el cliente sube un flujo (chunked upload).

• Bidirectional: ambos streamean (telemetría, chat, pricing en tiempo real).

En proyectos con streams largos me he topado con backpressure; me funcionó limitar tamaño máximo de mensaje, aplicar flow control y batching en el cliente.

Primer proyecto con gRPC (Go/Node/.NET/Java)

1) Define el .proto y piensa en compatibilidad hacia atrás: añade campos nuevos con índices nuevos, evita renumerar, usa valores por defecto razonables.

2) Genera stubs con el plugin del lenguaje.

• Go: protoc --go_out --go-grpc_out=. your.proto

• Node: @grpc/grpc-js + @grpc/proto-loader o codegen.

3) Timeouts, cancelaciones y reintentos

• Deadlines siempre (evita colas zombi).

• Retries con backoff exponencial y límites.

• Centraliza esto con interceptores; además, te sirven para tracing y métricas.

4) Errores con semántica

• Usa códigos gRPC (e.g., INVALID_ARGUMENT, NOT_FOUND, UNAVAILABLE).

• Añade detalles estructurados para debugging seguro.

Cuando probé a formalizar este “esqueleto” (deadlines, interceptores, reintentos) al inicio, los incidentes por timeouts encadenados cayeron de forma notable.

Seguridad y observabilidad en producción

Seguridad

• mTLS por defecto en interno (identidad de cliente/servidor).

• Rotación de certificados y políticas de autorización por método.

• Sensibiliza sobre tamaño de mensajes y rate limits (unary y streaming).

Observabilidad

• Interceptors para tracing distribuido (OpenTelemetry), latencias p95/p99, recuento por código gRPC.

• Health checks y load balancing coherente con tus sidecars o ingress.

En producción me funcionó instrumentar cada método con labels por servicio y versión del contrato; cuando hicimos canary de un .proto nuevo, la tasa de errores se detectaba por versión y el rollback era trivial.

Despliegue y rendimiento

Kubernetes

• Exponer gRPC a través de Ingress compatible (HTTP/2).

• Afinar maxConcurrentStreams y keepalives del lado servidor.

Tuning

• Ajusta message size y window para streams pesados.

• Pool de conexiones: reutiliza canales, evita crear/desechar sockets por llamada.

En un pipeline de telemetría, el paso a client-streaming + batching de 100 registros redujo p95 y coste de red a la mitad frente a llamadas unary.

FAQ rápidas de gRPC

¿Qué lenguajes soporta y cómo genero stubs?
Prácticamente todos los populares (Go, Java/Kotlin, .NET, Node, Python, Ruby…). Usa protoc con el plugin del lenguaje o herramientas específicas.

¿Cómo pruebo gRPC (incluido Postman)?
Hoy existen clientes GUI (Postman/Insomnia) que entienden .proto y permiten hacer llamadas unary y streaming básico.

¿Qué patrones de versionado recomiendas?
Añadir campos (no renumerar), evitar borrar; documentar evolución semántica por método; feature flags para cambios de comportamiento.

¿Cuándo no conviene gRPC?
APIs públicas orientadas a navegador, SEO, cachés HTTP, o integraciones donde tus consumidores no soportan HTTP/2/Protobuf.

Conclusión

gRPC no es “el nuevo REST”, es otra herramienta con trade-offs claros. Si priorizas baja latencia, contratos estrictos y streaming, es difícil de batir. Si tu prioridad es alcance y compatibilidad universal, REST/GraphQL siguen reinando. Mi recomendación: gRPC para tráfico interno crítico y REST/GraphQL en el borde.