Cuando los microservicios se multiplican, la latencia entre ellos se vuelve un dolor de cabeza. Aquí entra gRPC, un framework creado por Google que reinventa el viejo Remote Procedure Call para hacerlo más veloz, eficiente y apto para arquitecturas distribuidas modernas. Si trabajas con servicios que necesitan hablar entre sí en tiempo real, esto te interesa.

Qué es RPC y cómo funciona la llamada remota

Antes de entrar a gRPC, conviene entender la base. RPC significa Remote Procedure Call y es un protocolo donde un cliente le pide a un servidor que ejecute una rutina de código y devuelva una respuesta.

Lo interesante es cómo se ve a nivel de código. El cliente escribe algo como client.setStudent(...) y pasa los parámetros, como si ese método viviera dentro del cliente. Pero la realidad es otra: la implementación de setStudent vive del lado del servidor. RPC oculta por completo esa implementación remota y la hace ver local.

¿Qué es RPC en pocas palabras? Es un protocolo que permite a un cliente invocar funciones que se ejecutan en un servidor remoto, pero usando una sintaxis idéntica a la de una llamada local.

Por qué Google creó gRPC y qué lo hace más rápido

Google vio que el RPC tradicional tenía margen para volverse mucho más eficiente, así que construyó un framework con dos decisiones técnicas clave: usar HTTP/2 como capa de transporte y Protobufs como formato de intercambio de datos.

Con esa combinación, gRPC consigue mover más información, en menos tiempo y con conexiones más estables. Y aquí viene lo interesante: cada una de esas piezas resuelve un cuello de botella distinto.

Qué ventajas trae HTTP/2 frente a HTTP/1

La diferencia entre HTTP/2 y HTTP/1 no es cosmética, es de rendimiento puro. Estas son las mejoras que aprovecha gRPC:

• Multiplexación: permite enviar varios mensajes de forma simultánea sobre la misma conexión TCP, sin abrir conexiones nuevas.
• Serialización binaria: HTTP/2 soporta enviar data serializada, mientras que HTTP/1 solo acepta texto plano.
• Reutilización de conexión: hablar con el servidor se vuelve más liviano porque no hay que reabrir el canal cada vez.

Eso significa más requests, más data y menos espera entre cliente y servidor.

Qué papel cumplen los Protobufs en gRPC

Los Protobufs, o Protocol Buffers, son el método con el que gRPC serializa y deserializa la información. Esa serialización binaria pesa menos que el texto plano y se procesa más rápido en ambos extremos.

¿Por qué Protobufs es más rápido que JSON? Porque codifica la data en formato binario compacto, lo que reduce el tamaño del mensaje y acelera la serialización frente al texto plano de JSON.

Cómo funciona el streaming en gRPC y cuáles son sus métodos

Una de las peculiaridades más potentes de gRPC es el streaming: la capacidad de enviar datos de manera constante a través de un canal abierto. Esto abre la puerta a cuatro tipos de comunicación entre cliente y servidor.

Cuáles son los cuatro tipos de métodos en gRPC

Cada método responde a un patrón de comunicación distinto, y elegir el correcto depende del caso de uso:

1. Unario: el cliente envía una petición y el servidor responde una vez. Es el patrón más parecido a REST.
2. Streaming del lado del cliente: el cliente envía múltiples mensajes y el servidor responde una sola vez al final.
3. Streaming del lado del servidor: el cliente hace una petición única y el servidor responde con un flujo continuo de datos en pequeñas partes.
4. Streaming bidireccional: tanto cliente como servidor envían flujos de datos por el mismo canal.

Un detalle importante del streaming bidireccional: el cliente puede enviar M mensajes y el servidor responder con N mensajes. No existe obligación de comunicación uno a uno. Si tu cliente envía cinco veces, el servidor puede responder dos, diez o ninguna; depende de la lógica del servicio.

Para quién tiene sentido usar gRPC en lugar de REST

gRPC nace con una intención clara: crear RPC más eficientes y más rápidos apoyándose en HTTP/2, Protobufs y streaming. Si tu arquitectura tiene microservicios que se comunican intensamente entre sí, o si necesitas enviar grandes volúmenes de datos en tiempo real, este framework te va a dar ventajas que REST tradicional no ofrece.

Ahora bien, JSON sigue siendo el estándar de la web y es lo que usamos al trabajar con REST. Entonces, ¿por qué deberías cambiarte a Protobufs? Esa comparación a fondo, con sus ventajas y limitaciones, la dejamos para la siguiente clase. Cuéntame en los comentarios qué arquitectura estás usando hoy y si ya consideraste mover parte de tu comunicación a gRPC.