Cuando los microservicios resolvieron varios problemas de las arquitecturas monolíticas, surgieron nuevos retos: la latencia y la tardanza en la comunicación entre servicios se convirtieron en un obstáculo real. Aquí es donde entran en juego dos conceptos fundamentales que cambian la forma en que los servicios se comunican entre sí.
¿Qué es RPC y por qué parece código local?
RPC, o remote procedure call [0:32], es un protocolo que establece comunicación entre un cliente y un servidor. El cliente le indica al servidor que ejecute cierta rutina o subrutina de código y que le devuelva una respuesta.
Lo interesante es cómo luce a nivel de código. Cuando el cliente hace algo como client.setStudent(params), parece que ese método vive dentro del propio cliente. Pero en realidad, toda la implementación de setStudent reside en el servidor [1:03]. RPC oculta por completo esa separación, haciendo que la invocación sea invisible para el cliente, como si los métodos fueran suyos.
Esta abstracción es poderosa porque simplifica enormemente el desarrollo distribuido.
¿Cómo mejoró Google el rendimiento con gRPC?
Google tomó el concepto de RPC y creó gRPC, un framework diseñado para ser más rápido, eficiente y de alto rendimiento [1:40]. Las dos mejoras clave que lo distinguen son:
- HTTP 2.0 en lugar de HTTP 1.0.
- Protocol Buffers (protobuffers) como método de intercambio de datos.
¿Por qué HTTP 2.0 marca la diferencia?
HTTP 2.0 introduce la multiplexación [2:20], que permite utilizar la misma conexión TCP para enviar múltiples mensajes de manera simultánea. Esto significa más peticiones al mismo tiempo y mayor velocidad.
Además, HTTP 2.0 permite serializar datos y enviarlos a través de las peticiones [2:47]. HTTP 1.0 solo acepta texto plano, lo cual limita considerablemente la eficiencia del transporte.
¿Qué aportan los protobuffers?
Los protobuffers complementan esta ventaja al ofrecer capacidades de serialización y deserialización que hacen el intercambio de datos significativamente más rápido [2:56]. En conjunto, gRPC aprovecha ambas tecnologías para enviar más requests, más datos y hacerlo en menos tiempo.
¿Qué tipos de streaming ofrece gRPC?
Una de las características más distintivas de gRPC es el streaming [3:16], que permite enviar datos de manera constante a través de un canal abierto. Existen cuatro métodos de comunicación:
- Método unario: el cliente envía una petición y el servidor responde una sola vez [3:34]. Es el más tradicional, similar a REST.
- Streaming del lado del cliente: el cliente envía datos múltiples veces y el servidor responde con una única respuesta [3:53].
- Streaming del lado del servidor: el cliente solicita una sola vez y el servidor responde con un flujo continuo de datos en partes pequeñas [4:10].
- Streaming bidireccional: tanto el cliente como el servidor se comunican mediante flujos de datos simultáneos [4:27].
Un detalle importante es que la comunicación no tiene que ser uno a uno [4:40]. Si el cliente envía cinco mensajes (M mensajes), el servidor puede responder con un número distinto (N mensajes). No existe la obligación de paridad.
¿Por qué no simplemente usar JSON?
JSON es el estándar de la web y ha sido la forma habitual de intercambiar datos en arquitecturas REST [5:08]. Entonces surge la pregunta lógica: ¿por qué los protobuffers son mejores que JSON para este contexto? La respuesta tiene que ver con la eficiencia en la serialización, el tamaño de los mensajes y la velocidad de procesamiento, aspectos que marcan una gran diferencia cuando la comunicación entre servicios debe ser extremadamente rápida.
gRPC nace con la intención clara de crear comunicaciones entre servicios más eficientes, combinando HTTP 2.0, protobuffers y streaming. Si ya has trabajado con REST y JSON, ¿te imaginas implementando gRPC en tus proyectos? Comparte tu perspectiva sobre cuándo elegirías uno sobre otro.
