¿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 vistas 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, de hecho, es un intermediario. Este intermediario se conoce comúnmente como stub, que maneja los datos de serialización y desclasificación (es decir, convertir los datos a un formato adecuado para la transmisión y convertir los resultados recibidos del servidor 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 infraestructuras 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 las fortalezas de RPC: simplificaron el desarrollo, abstrajeron las complejidades de la comunicación de red, son livianas, relativamente fáciles 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 una infraestructura más rápida y de alto rendimiento para conectar aplicaciones distribuidas. Idealmente, esta infraestructura 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 con implementaciones de 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 API creadas con gRPC sean una opción sólida para entornos modernos y distribuidos, arquitecturas de microservicios, aplicaciones de transmisión y para conectar sistemas y dispositivos de Internet de las cosas.

Tendría sentido si gRPC significara "Google Remote Procedure Call". 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 compatibilidad para lenguajes modernos y características y optimizaciones adicionales. Las características incluyen:

• Un lenguaje de diseño de interfaz (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 registro, rastreo, autenticación y 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 usa Java puede comunicarse con una que usa Python porque la solicitud se convierte en la lingua franca del binario. Aunque los humanos no pueden leerlo, el binario es más rápido de transmitir y decodificar con computadoras 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" e "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 cómo desea que se estructuren sus datos una vez, luego puede usar un código fuente especialmente generado para escribir y leer fácilmente sus datos estructurados hacia y desde una variedad de flujos de datos y usando una variedad de lenguajes”. Como intermediario, Protobuf también permite la instalación de varias medidas de autenticación y seguridad.

Los desarrolladores pueden usar 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 cumple muchas funciones: normalmente incluye clases o módulos, maneja la serialización en binario y la deserialización de binario y abstrae las complejidades del intercambio de datos. Los desarrolladores no necesitan 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 agregar nuevos campos de datos a las estructuras existentes sin irrumpir en 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 tardar algo de tiempo y esfuerzo en configurarse en primer lugar.

HTTP/2 es un protocolo de transporte, un método que utilizan las computadoras y los servidores para intercambiar información, que utiliza un formato binario para enviar mensajes, reduce las conexiones TCP y utiliza 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 transmisiones simultáneas 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 de 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, transmisión del lado del cliente, transmisión del lado del servidor y transmisión 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, registro, métricas, equilibrio de carga, verificación de estado y 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.

Transmisión bidireccional: el cliente y el servidor envían múltiples llamadas de ida y vuelta simultáneamente, lo que permite la comunicación en tiempo real.

Tanto gRPC como REST son estilos arquitectónicos que se utilizan comúnmente en el diseño de API. Tienen muchas similitudes; ambos siguen una arquitectura cliente/servidor, dependen de 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, aunque hay plug-ins disponibles.

Patrón de diseño: gRPC tiene un diseño orientado a servicios, en el que las operaciones del servidor invocables se definen como servicios o funciones. En REST, el diseño está orientado a los recursos, en el que se emplean métodos HTTP para acceder a los 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 prototipo 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 múltiples 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 manejar grandes volúmenes de datos y capacidad de transmisión bidireccional en tiempo real, gRPC se utiliza a menudo para crear API para microservicios.

Debido a que 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 mecanografiado que ayuda a salvaguardar la integridad de los datos de 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 continuos, como videoconferencias o cuando un usuario quiere usar 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 de datos coherente entre estos dispositivos.

Con su soporte de streaming bidireccional y capacidades amigables con los microservicios (y su estado como proyecto CNCF), gRPC se usa 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 que se define 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. Estos beneficios 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: debido a que gRPC utiliza búferes de protocolo (un mecanismo de serialización independiente del lenguaje y la plataforma) para describir estructuras de datos e interfaces RPC, se puede usar para permitir la comunicación entre servicios escritos en varios lenguajes en diferentes plataformas.

Reducción de errores de tiempo de ejecución: Protobuf proporciona una escritura sólida, lo que significa que aplica una estructura de datos firme y definida explícitamente. La tipificación segura 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ísticas, como medidas de seguridad y autenticación o herramientas de analytics.

Si bien 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 principal, la complejidad introducida por gRPC podría ser innecesaria. Los desafíos de gRPC incluyen:

Complejidad: definir estructuras de mensajes y servicios en archivos .proto, como requiere gRPC, puede ser más desafiante 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 o tanto soporte de complementos y documentación. Como infraestructura más nueva, hay menos herramientas (como herramientas de análisis de seguridad) disponibles para gRPC en comparación con algunas infraestructuras más establecidas.

Limitaciones del navegador: debido a que los navegadores web no admiten de forma nativa 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 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 convierte la solicitud en una solicitud de gRPC estándar y la reenvía al servidor backend de 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.