¿Qué es gRPC?

RPC, o llamada a procedimiento remoto, es un modelo de comunicación para la interacción cliente/servidor que permite que las llamadas remotas aparezcan y funcionen como llamadas locales. Es una técnica más antigua, que se remonta conceptualmente a la década de 1970, con aplicaciones iniciales observadas en proyectos informáticos pioneros como ARPANET y Xerox PARC.

En una RPC, el cliente interactúa con una representación del servidor, que parece local pero que en realidad es un intermediario. Este intermediario se conoce comúnmente como stub, que gestiona los datos de clasificación y desclasificación (es decir, convertir los datos a un formato adecuado para la transmisión y convertir los resultados recibidos del servidor de nuevo al formato original). Debido a que es un estilo arquitectónico para la comunicación cliente/servidor, se usa comúnmente en el diseño de API.

Hay muchas implementaciones diferentes de marcos RPC, incluidos XML-RPC y JSON-RPC. Estas implementaciones utilizan HTTP como protocolo de transporte, y difieren principalmente en el tipo de formato. Estas implementaciones, que se remontan a las décadas de 1990 y 2000, mostraron los puntos fuertes de RPC: simplificaron el desarrollo, abstrajeron las complejidades de la comunicación de red, son ligeras, relativamente sencillas de usar y legibles por humanos.

Sin embargo, muchos entornos modernos, especialmente aquellos que utilizan arquitecturas de microservicios, entornos políglotas y sistemas con altas cargas de datos, requieren un marco más rápido y de alto rendimiento para conectar aplicaciones distribuidas. Idealmente, este marco facilita una transferencia de datos más eficiente y en tiempo real entre servicios que se ejecutan en diferentes entornos y centros de datos.

gRPC se desarrolló para satisfacer esta necesidad, ofreciendo baja latencia y alto rendimiento a través de la serialización de datos y su uso del protocolo HTTP/2, capacidades de transmisión bidireccional, generación de código y más.

gRPC se lanzó inicialmente en 2015, el mismo año que el lanzamiento de HTTP/2. Aborda las limitaciones de las implementaciones RPC más antiguas principalmente mediante el uso de Protocol Buffers, o Protobuf, su lenguaje de definición de interfaz (IDL). Protobuf serializa y codifica datos estructurados en binario. Esto hace que los datos sean más compactos, lo que permite una transmisión más rápida y un mayor rendimiento.

Protobuf también permite cambios en los campos de datos sin interrumpir el código. Esto ayuda a reducir los errores y permite compartir y procesar datos en tiempo real. Estas características hacen que las APIs construidas con gRPC sean una opción sólida para entornos modernos y distribuidos, arquitecturas de microservicios, aplicaciones de streaming y para conectar sistemas y dispositivos de Internet de las cosas.

Tendría sentido que gRPC significara "Llamada a procedimiento remoto de Google". Pero el equipo de gRPC en grpc.io afirma descaradamente que significa "gRPC Remote Procedure Call". Su GitHub señala que la "g" significa algo diferente con cada versión (que va desde "gregarious" hasta "goose" y "Guadalupe River Park Conservancy"). En cualquier caso, Google desarrolló gRPC y lo lanzó como proyecto de código abierto en 2015.

gRPC presenta una versión moderna y actualizada de RPC, con soporte para lenguajes modernos y características y optimizaciones adicionales. Sus características incluyen:

• Un lenguaje de diseño de interfaces (IDL) llamado Protocol Buffers
• Uso de HTTP/2 para la transmisión de datos
• Streaming bidireccional
• Generación de código
• Cuatro tipos de métodos
• Integración con seguridad basada en TLS
• Compatibilidad con interceptores para información de registro, seguimiento, autenticación y mucho más

Protocol Buffers, comúnmente conocido como Protobuf, es un formato de datos multiplataforma desarrollado por Google que se utiliza para serializar datos estructurados. En efecto, sirve como un poderoso intermediario entre el cliente y el servidor que serializa las solicitudes en código binario para su transmisión.

Este mecanismo es flexible y eficiente, lo que permite el agnosticismo del lenguaje de programación, el tamaño reducido de los mensajes y un análisis y transmisión más rápidos, todo al mismo tiempo. Una aplicación que utiliza Java puede comunicarse con una que utiliza Python porque la solicitud se convierte en la lingua franca del binario. Aunque no es legible por humanos, el binario es más rápido de transmitir y decodificar con ordenadores que un formato basado en texto como JSON.

Básicamente, los desarrolladores crean un archivo de texto con el sufijo ".proto" que contiene toda la información sobre la estructura de datos. Esta información se basa en esquemas, lo que significa que define parámetros, métodos y posibles resultados, una descripción de la estructura de los datos. Por ejemplo, puede tener una entrada para "usuario", que indica que estos datos incluirán "nombre", "dirección de correo electrónico" y "ingrediente de pizza favorito".

Según la documentación de Protobuf, es como XML, "pero más pequeño, más rápido y más simple. Usted define una vez cómo desea que se estructuren sus datos y, a continuación, puede utilizar código fuente generado especialmente para escribir y leer fácilmente sus datos estructurados en una variedad de flujos de datos y utilizando una variedad de lenguajes". Como intermediario, Protobuf también permite la instalación de varias medidas de autenticación y seguridad.

Los desarrolladores pueden utilizar un compilador, llamado Protoc, para generar código en cualquiera de los varios lenguajes compatibles, incluidos C#, C++, Dart, Go, Java, Kotlin, Node.js, Objective-C, PHP, Python y Ruby. Este código tiene muchas funciones: normalmente incluye clases o módulos, gestiona la serialización en binario y la deserialización desde binario, y abstrae las complejidades del intercambio de datos. Los desarrolladores no tienen que preocuparse por el empaquetado de la red, la clasificación, la actualización para la compatibilidad y la implementación; Protobuf se encarga de todo.

El diseño basado en esquemas de Protobuf permite a los desarrolladores añadir nuevos campos de datos a las estructuras existentes sin romper todo el sistema. También reduce en gran medida el esfuerzo necesario para actualizar, mantener y manejar tareas tediosas relacionadas con la API, como ajustar el código anterior después de agregar nuevos campos de datos. Dicho esto, los archivos .proto pueden requerir algo de tiempo y esfuerzo para configurarlos inicialmente.

HTTP/2 es un protocolo de transporte (un método que utilizan los ordenadores y servidores para intercambiar información) que utiliza un formato binario para enviar mensajes, reduce las conexiones TCP y utiliza la compresión de encabezados, todo lo cual ayuda a que sea más rápido y eficiente que su predecesor ( HTTP/1.1). También permite la multiplexación, o la capacidad de enviar múltiples flujos simultáneos en una sola conexión; gRPC utiliza lo que se denomina canales para habilitar múltiples flujos a través de esas múltiples conexiones. Los mensajes se envían como tramas de datos HTTP/2, cada una de las cuales puede contener varios mensajes gRPC.

gRPC ofrece streaming bidireccional, en el que tanto el cliente como el servidor pueden enviar mensajes de forma independiente en un flujo de lectura/escritura. Este método permite todo tipo de flexibilidad: un servidor y un cliente pueden intercambiar respuestas secuencialmente, o un servidor puede esperar hasta que se hayan recibido todos los mensajes del cliente antes de responder. Esta característica se puede ajustar de acuerdo con aplicaciones específicas.

gRPC utiliza una herramienta de compilación llamada protoc para generar automáticamente código de cliente y servidor en varios lenguajes basados en definiciones de servicio y estructuras de mensajes definidas en un archivo .proto . Los complementos se pueden utilizar para ampliar la compatibilidad con muchos más idiomas.

Protoc genera clases de acceso a datos en el lenguaje definido en la definición proto. Estas clases proporcionan accesores simples para campos como [name], así como métodos para serializar y analizar la estructura hacia y desde bytes sin procesar¹.

gRPC admite cuatro tipos de métodos diferentes para la transmisión de datos: unario, streaming del lado del cliente, streaming del lado del servidor y streaming bidireccional.

gRPC tiene integración incorporada con TLS (seguridad de la capa de transporte), que cifra los intercambios de datos entre el cliente y el servidor y permite a los usuarios ayudar a proteger las conexiones.

gRPC admite autenticación conectable, seguimiento, información de registro, métricas, equilibrio de carga, comprobación de estado y mucho más. 

gRPC tiene cuatro tipos diferentes de métodos, que indican cómo un cliente gRPC y un servidor gRPC envían y reciben un mensaje. Esos tipos son:

Unario: una llamada simple en la que un cliente envía una sola solicitud y un servidor responde con una sola respuesta.

Streaming del lado del servidor: una llamada en la que un cliente envía una solicitud, pero el servidor responde con múltiples respuestas.

Streaming del lado del cliente: una llamada en la que un cliente envía varias solicitudes y un servidor responde con una sola respuesta. El servidor puede optar por esperar a que cese todo el flujo de solicitudes de los clientes antes de procesarlas y responderlas.

Streaming bidireccional: el cliente y el servidor envían varias llamadas de un lado a otro al mismo tiempo, lo que permite la comunicación en tiempo real.

Tanto gRPC como REST son estilos arquitectónicos que se utilizan habitualmente en el diseño de API. Tienen muchas similitudes; ambos siguen una arquitectura cliente/servidor, se basan en la comunicación basada en HTTP, no tienen estado y son independientes del idioma. Pero también difieren en aspectos clave que hacen que cada uno sea ideal para diferentes casos de uso.

Formato de datos: las API REST utilizan formatos de texto sin formato como JSON y XML. gRPC utiliza Protobuf para codificar datos en binario.

Patrón de comunicación: gRPC admite cuatro métodos: unario, streaming de servidor, streaming de cliente y streaming bidireccional. REST utiliza un sistema unario de solicitud y respuesta.

Generación de código: gRPC ofrece generación de código integrada; REST no lo hace, aunque hay complementos disponibles.

Patrón de diseño: gRPC tiene un diseño orientado a servicios, en el que las operaciones de servidor invocables se definen como servicios o funciones. En REST, el diseño se orienta en torno a recursos, en los que se utilizan métodos HTTP para acceder a recursos del servidor a través de endpoints definidos por URL.

Protocolo: gRPC utiliza HTTP/2, mientras que REST se basa en HTTP/1.1.

Acoplamiento: el cliente y el servidor de gRPC están estrechamente acoplados, lo que significa que tanto el cliente como el servidor deben tener acceso al mismo archivo de proto de middleware. Cualquier cambio en uno requiere un cambio en el otro. REST está débilmente acoplado. Esta independencia significa que los cambios en un componente no afectan al otro.

gRPC se utiliza a menudo para API complejas que conectan varios servicios en un entorno distribuido. Su capacidad de transmisión en tiempo real y su alto rendimiento hacen que gRPC sea una buena opción para varios casos de uso, incluidos microservicios, transmisión y conexión de clientes de Internet de las cosas.

Debido a su alto rendimiento, baja latencia, capacidad para gestionar grandes volúmenes de datos y capacidad de transmisión bidireccional en tiempo real, gRPC se utiliza a menudo para crear API para microservicios.

Como gRPC es independiente del lenguaje, puede permitir la comunicación entre servicios escritos en diferentes lenguajes de programación. Además, las definiciones de Protobuf proporcionan un esquema fuertemente tipado que ayuda a proteger la integridad de los datos de los microservicios.

Las capacidades de transmisión bidireccional de gRPC significan que puede transmitir datos simultáneamente en ambas direcciones entre el cliente y el servidor a través de una única conexión de red. Esta capacidad hace que gRPC sea ideal para procesos en curso, como videoconferencias o cuando un usuario desea utilizar parte de un conjunto de datos mientras se transfieren otros datos.

El Internet de las cosas se refiere a una red de dispositivos o clientes conectados. Los dispositivos IoT, también conocidos como "objetos inteligentes", pueden incluir dispositivos simples de "hogar inteligente", como termostatos inteligentes, wearables como relojes inteligentes y ropa habilitada para RFID y maquinaria industrial compleja y sistemas de transporte². Las API de gRPC se utilizan a menudo para facilitar el intercambio coherente de datos entre estos dispositivos.

Con su soporte de transmisión bidireccional y sus capacidades amigables con los microservicios (y su estado como proyecto CNCF), gRPC se utiliza cada vez más para las API nativas de la nube.

gRPC se utiliza para generar bibliotecas cliente en muchos lenguajes de programación diferentes. Estas bibliotecas se generan en función de la definición de servicio proporcionada en archivos .proto; una vez definido el servicio, gRPC genera automáticamente código de cliente en un lenguaje de programación elegido.

Esta capacidad simplifica el trabajo de los desarrolladores, permitiéndoles centrarse en la lógica de la aplicación en lugar del código de comunicación de bajo nivel.

gRPC ofrece muchos beneficios para las organizaciones y los desarrolladores que crean API con requisitos de alto rendimiento. Entre estos beneficios se incluyen:

Transmisión más rápida y eficiente: hay varios factores que contribuyen al alto rendimiento de gRPC. Por un lado, la serialización de Protobuf reduce el tamaño de los mensajes y los paquetes más pequeños se pueden transmitir más rápidamente. El binario también se analiza de manera más eficiente que los formatos de texto sin formato como JSON o XML.

Además, gRPC utiliza HTTP/2, que es más rápido y eficiente que HTTP/1.1, reduciendo aún más la latencia y el uso del ancho de banda.

Mayor portabilidad: dado que gRPC utiliza búferes de protocolo (un mecanismo de serialización independiente del idioma y de la plataforma) para describir estructuras de datos e interfaces RPC, se puede utilizar para permitir la comunicación entre servicios escritos en varios idiomas en diferentes plataformas.

Reducción de errores de tiempo de ejecución: Protobuf proporciona una tipificación fuerte, lo que significa que aplica una estructura de datos firme y definida explícitamente. La tipificación fuerte promueve la coherencia y la detección temprana de errores, lo que reduce la posibilidad de errores en tiempo de ejecución.

Personalización flexible: la compatibilidad integrada con middleware permite la personalización y la adición de característica, como medidas de seguridad y autenticación o analytics.

Aunque gRPC tiene muchas ventajas, no está exento de desafíos. En algunos casos, por ejemplo, API públicas con fuentes de datos simples donde la facilidad de uso es una consideración primordial, la complejidad introducida por gRPC puede ser innecesaria. Los desafíos de gRPC incluyen:

Complejidad: definición de estructuras de mensajes y servicios en archivos .proto como requiere gRPC, puede ser más difícil que trabajar con formatos basados en texto como XML y JSON.

Facilidad de uso: gRPC, búferes de protocolo y HTTP/2 pueden presentar una curva de aprendizaje pronunciada para los desarrolladores acostumbrados a trabajar con REST.

Depuración: puede ser difícil inspeccionar, depurar y registrar aplicaciones gRPC porque el formato binario no es legible por humanos. Hay herramientas que pueden convertir binarios, pero requieren un paso adicional, en comparación con XML o JSON.

Actualidad y soporte: gRPC no es tan antiguo como otros estilos arquitectónicos populares como REST y no tiene una comunidad tan grande ni tanto soporte de complementos y documentación. Como marco más nuevo, hay menos herramientas (como herramientas de escáner de seguridad) disponibles para gRPC en comparación con algunos estilos más establecidos.

Limitaciones del navegador: dado que los navegadores web no son compatibles de forma nativa con el protocolo gRPC, no es posible llamar directamente a un servicio gRPC desde una aplicación basada en navegador. Una forma de solucionar este problema es utilizar un proxy como gRPC-Web. gRPC-Web actúa esencialmente como una capa de traducción entre el protocolo HTTP y gRPC de un navegador.

La aplicación web inicia una llamada gRPC utilizando la biblioteca de cliente gRPC-Web JavaScript para enviar una solicitud gRPC que se ha adaptado para la compatibilidad con el navegador. La solicitud se envía a un servidor proxy que la convierte en una solicitud gRPC estándar y la reenvía al servidor backend gRPC. El servidor gRPC procesa la solicitud, devuelve una respuesta al servidor proxy y el proxy vuelve a convertir la respuesta al formato gRPC-Web antes de devolverla al cliente.