La te­c­no­lo­gía de las redes sigue avanzando a una velocidad de vértigo. Con el objetivo de cumplir las demandas cada vez más exigentes de los sistemas in­fo­r­má­ti­cos di­s­tri­bui­dos, se ha de­sa­rro­lla­do un nuevo sistema de­no­mi­na­do gRPC para las Remote Procedure Calls o llamadas a pro­ce­di­mie­n­to remoto. La “g” es de Google, ya que la empresa jugó un papel de­te­r­mi­na­n­te en el de­sa­rro­llo del sistema. Te ex­pli­ca­mos qué es gRPC, cómo funciona y dónde se utiliza.

¿Qué es gRPC?

gRPC es un moderno sistema de llamada a pro­ce­di­mie­n­to remoto que procesa la co­mu­ni­ca­ción en es­tru­c­tu­ras cliente-servidor di­s­tri­bui­das de manera es­pe­cia­l­me­n­te eficiente gracias a una in­no­va­do­ra in­ge­nie­ría de procesos. Actúa en el nivel del proceso, al igual que su antecesor, el sistema RPC. Un elemento ca­ra­c­te­rí­s­ti­co de la co­mu­ni­ca­ción entre procesos mediante gRPC es el principio de tra­n­s­pa­re­n­cia: la co­la­bo­ra­ción entre in­s­ta­n­cias (en parte muy) di­s­ta­n­cia­das es tan estrecha y sencilla que no se percibe ninguna di­fe­re­n­cia en co­m­pa­ra­ción con una co­mu­ni­ca­ción local entre procesos internos de una máquina.

De­sa­rro­lla­do por Google en el año 2015, hoy es la Cloud Native Computing Fou­n­da­tion la encargada de su di­s­tri­bu­ción y de­sa­rro­llo. gRPC es un elemento de código abierto, es decir, el código fuente está accesible para que otros de­sa­rro­lla­do­res hagan mo­di­fi­ca­cio­nes y pa­r­ti­ci­pen en su de­sa­rro­llo.

Por defecto, gRPC ejecuta el tra­n­s­po­r­te de flujos de datos entre or­de­na­do­res alejados mediante HTTP/2 y gestiona la es­tru­c­tu­ra y la di­s­tri­bu­ción de los datos mediante los Protocol buffers de­sa­rro­lla­dos por Google. Estos últimos se guardan en forma de archivos de texto plano con la extensión .proto.

A menudo, gRPC se define como un tipo de framework. Una de las ca­ra­c­te­rí­s­ti­cas de­s­ta­ca­das de los fra­me­wo­r­ks es que pro­po­r­cio­nan un marco de pro­gra­ma­ción a los de­sa­rro­lla­do­res para ahorrar tiempo y trabajo. La es­tru­c­tu­ra es­ta­n­da­ri­za­da de gRPC ya incluye di­fe­re­n­tes funciones y elementos que no hay que programar una y otra vez cada vez que se necesitan. El marco gRPC define además in­te­r­fa­ces no­r­ma­li­za­das para acceder a de­te­r­mi­na­das fuentes (p. ej., bases de datos).

Así funciona gRPC: mu­l­ti­li­n­güe y eficiente gracias a Protocol Buffers y HTTP/2

Los Protocol Buffers (Protobuf) cumplen varias funciones en el sistema gRPC: sirven como lenguaje de de­s­cri­p­ción de interfaz (Interface De­fi­ni­tion Language, IDL) y describen una interfaz de manera in­de­pe­n­die­n­te de cualquier lenguaje, es decir, no están vi­n­cu­la­dos a un lenguaje de pro­gra­ma­ción es­pe­cí­fi­co (p. ej., Java o C). También definen los servicios que se deben emplear y las funciones di­s­po­ni­bles. Para cada función, puede indicarse qué pa­rá­me­tros se envían con una consulta y qué valor de respuesta se puede esperar.

Desde la pe­r­s­pe­c­ti­va remota, los Protocol Buffers sirven como el formato su­b­ya­ce­n­te de in­te­r­ca­m­bio de mensajes que determina las es­tru­c­tu­ras, los tipos y los objetos de los mensajes. Son los elementos que hacen que el cliente y el servidor se “entiendan” y que funcionen como una unidad funcional y lo más eficiente posible, incluso a gran distancia.

El proceso de una solicitud gRPC en caso de una consulta de base de datos (p. ej., “búsqueda de stock de un artículo en el almacén”) sería el siguiente:

  • Antes de que se pueda llevar a cabo la búsqueda, hay que realizar ciertos pre­pa­ra­ti­vos. En el lado del servidor, primero se im­ple­me­n­tan un servicio y un servidor gRPC sobre la base de los Protocol Buffers. El cliente que hace la consulta, por su parte, genera el stub co­rre­s­po­n­die­n­te. Si está di­s­po­ni­ble, la apli­ca­ción de cliente llama a la función co­rre­s­po­n­die­n­te (“consulta de búsqueda de stock de un artículo”) en el stub.
  • A co­n­ti­nua­ción, la consulta se envía al servidor a través de la red. Una vez recibida la consulta con ayuda de una interfaz de servicio adecuada, es cuando el servidor gRPC inicia la búsqueda real del producto en la base de datos.
  • Entonces el servidor envía una respuesta al stub del cliente que, a su vez, transmite el valor de respuesta a la instancia de consulta original (p. ej., “número de artículos en­co­n­tra­dos”).

Tanto las apli­ca­cio­nes del lado del cliente, como las del lado servidor, se pueden escribir en di­fe­re­n­tes lenguajes de pro­gra­ma­ción. gRPC es capaz de superar estas barreras mediante in­te­r­fa­ces y me­ca­ni­s­mos de tra­du­c­ción es­pe­cia­les.

Para el tra­n­s­po­r­te de ida y vuelta de los flujos de datos entre máquinas (Proto Request y Proto Response) se integra HTTP/2 en pro­to­co­los de red es­pe­cí­fi­cos como TCP/IP o UDP/IP. Los flujos tra­n­s­mi­ten datos binarios compactos que surgen en la se­ria­li­za­ción (ma­r­sha­lli­ng) típica de las llamadas a pro­ce­di­mie­n­tos remotos. Para procesar estas es­tru­c­tu­ras de datos, to­ta­l­me­n­te ab­s­tra­c­tas, en los pasos si­guie­n­tes en el lado del servidor y en el lado del cliente, el contenido tra­n­s­mi­ti­do se vuelve a deseria­li­zar (un­ma­r­sha­lli­ng).

Imagen: Representación gráfica del intercambio de mensajes vía gRPC en una estructura cliente-servidor
In­te­r­ca­m­bio de mensajes vía gRPC en una es­tru­c­tu­ra cliente-servidor

El flujo de trabajo gRPC y primeros pasos con Protocol Buffers

El flujo de trabajo gRPC se divide en cuatro pasos:

  1. De­fi­ni­ción del contrato de servicio para la co­mu­ni­ca­ción entre procesos: se de­te­r­mi­nan los servicios que se deben aplicar y los pa­rá­me­tros y tipos de respuesta básicos a los que se puede acceder de manera remota.
  2. Ge­ne­ra­ción del código gRPC del archivo .proto: unos co­m­pi­la­do­res es­pe­cia­les (he­rra­mie­n­tas de líneas de comandos de­no­mi­na­das “protoc”) generan el código operativo con las clases co­rre­s­po­n­die­n­tes para un lenguaje de destino deseado (p. ej., C++, Java) a partir de los archivos .proto guardados.
  3. Im­ple­me­n­ta­ción del servidor en el lenguaje deseado.
  4. Creación del stub del cliente que llama al servicio; a co­n­ti­nua­ción, entre el servidor y el cliente se procesan las consultas.
Imagen: Representación gráfica del flujo de trabajo gRPC
Pasos básicos del flujo de trabajo gRPC

En el caso de una consulta de base de datos para de­te­r­mi­nar las exi­s­te­n­cias de un artículo en un almacén (inventory), los primeros pasos a seguir en la sintaxis actual de Protocol Buffer (versión: proto3) serían los si­guie­n­tes:

syntax = "proto3";
package grpc_service;
import "google/protobuf/wrappers.proto";
service InventoryService {
	rpc getItemByName(google.protobuf.StringValue) returns (Items);
	rpc getItemByID(google.protobuf.StringValue) returns (Item);
	 rpc addItem(Item) returns (google.protobuf.BoolValue);
}
 
message Items {
  string itemDesc = 1;
  repeated Item items = 2;
}
 
message Item {
	string id = 1;
	string name = 2;
	string description = 3;
}

En el ejemplo, la consulta de base de datos emplea “bi­blio­te­cas wrapper” es­pe­cia­les del framework gRPC que ya ponen a di­s­po­si­ción procesos re­le­va­n­tes de tra­du­c­ción de manera pre­de­fi­ni­da y se importan al inicio. En es­tru­c­tu­ras cliente-servidor mu­l­ti­li­n­gües y des­igua­les, estas bi­blio­te­cas permiten que in­te­r­fa­ces en principio in­co­m­pa­ti­bles puedan co­mu­ni­car­se. Así es como se generan, p. ej., las clases ne­ce­sa­rias para leer y escribir mensajes.

El siguiente gráfico muestra cómo la de­fi­ni­ción de servicio (inventory.proto) regula la consulta de una base de datos en una es­tru­c­tu­ra cliente-servidor:

Imagen: Representación gráfica de una consulta de base de datos con gRPC
Gestión de una consulta de base de datos con Protocol Buffers (archivo .proto)

HTTP/2: streaming op­ti­mi­za­do

HTTP/2 desempeña un papel de­te­r­mi­na­n­te para gRPC, ya que permite la tra­n­s­fe­re­n­cia de datos binarios compactos para aportar mayor efi­cie­n­cia al in­te­r­ca­m­bio de mensajes y datos. El protocolo pro­po­r­cio­na cuatro variantes para llamadas a pro­ce­di­mie­n­to remoto:

1. Las RPC unarias re­pre­se­n­tan el patrón gRPC más sencillo, por el cual el cliente envía una sola solicitud al servidor y, como en una llamada normal a una función, solo obtiene una respuesta.

Ejemplo: rpc SayHello (He­llo­Re­que­st) responde (He­llo­Re­s­po­n­se)

2. Las RPC de streaming de servidor permiten un in­te­r­ca­m­bio más complejo de mensajes dentro de una única llamada RPC. Primero, el cliente envía una solicitud al servidor. Entonces recibe como respuesta un hilo (stream) con una larga secuencia de mensajes (solicitud eficiente de mensajes dentro de una sola llamada RPC). A co­n­ti­nua­ción, el cliente lee el hilo hasta que no queden mensajes.

Ejemplo: rpc LotsO­fRe­plies (He­llo­Re­que­st) responde (stream He­llo­Re­s­po­n­se)

3. Las RPC de streaming de cliente invierten el proceso: el cliente escribe una secuencia de mensajes y la envía al servidor vía stream. Una vez que el cliente ha preparado los mensajes, espera a que el servidor los lea y le responda. En este caso, la solicitud de mensajes también se realiza dentro de una sola llamada RPC.

Ejemplo: rpc LotsO­f­Gree­ti­n­gs (stream He­llo­Re­que­st) responde (He­llo­Re­s­po­n­se)

4. Las RPC de streaming bi­di­re­c­cio­nal re­pre­se­n­tan la forma más compleja de co­mu­ni­ca­ción, en la cual ambos lados envían una secuencia de mensajes. Ambos streams de datos trabajan de manera in­de­pe­n­die­n­te entre sí, de manera que el cliente y el servidor pueden leer y escribir sin importar el orden. De esta manera, el servidor puede esperar a que entren todos los mensajes del cliente antes de redactar sus re­s­pue­s­tas, pero también puede escribir y leer mensajes de manera alterna. También se permite cualquier otra co­m­bi­na­ción de procesos de lectura y escritura.

Por ejemplo: rpc BidiHello (stream He­llo­Re­que­st) responde (stream He­llo­Re­s­po­n­se)

Gracias a las so­li­ci­tu­des anidadas, las variantes 2 a 4 permiten una mu­l­ti­ple­xa­ción es­pe­cia­l­me­n­te eficiente en la que en una sola conexión TCP se agrupan varias señales que se pueden tra­n­s­mi­tir de manera si­mu­l­tá­nea por la red. Los bloqueos del tráfico de datos se superan mediante el potente protocolo HTTP/2.

Imagen: Representación gráfica del streaming en HTTP/2
Variantes de streaming en HTTP/2

Ventajas y de­s­ve­n­ta­jas de gRPC

gRPC cuenta con numerosas ventajas: la te­c­no­lo­gía es fácil de aplicar, ya que, al crear los archivos .proto, emplea un IDL sencillo, fácil de aprender. Con él, incluso los programas an­ti­cua­dos pueden ampliarse con una potente interfaz gRPC, de forma que puedan tra­n­s­mi­tir archivos grandes no­ta­ble­me­n­te más rápido.

gRPC ha sido probado en múltiples ocasiones y es fá­ci­l­me­n­te escalable, por lo que también se puede aplicar en co­mu­ni­ca­cio­nes más complejas y amplias, p. ej., en es­tru­c­tu­ras cliente-servidor in­te­r­co­ne­c­ta­das a nivel global. Aquí, HTTP/2 no solo aumenta la efi­cie­n­cia gracias a la mu­l­ti­ple­xa­ción y el streaming bi­di­re­c­cio­nal, sino que también permite comprimir los en­ca­be­za­dos para reducir el volumen de datos de las so­li­ci­tu­des y re­s­pue­s­tas en la red de manera notable.

La es­tru­c­tu­ra en capas, fue­r­te­me­n­te es­ta­n­da­ri­za­da, del framework gRPC permite reducir el esfuerzo de pro­gra­ma­ción. De esta forma, los de­sa­rro­lla­do­res pueden centrar toda su atención en la apli­ca­ción de los métodos. Si se requieren ada­p­ta­cio­nes, los pro­gra­ma­do­res y de­sa­rro­lla­do­res de sistemas puedan apro­ve­char el acceso libre al código fuente.

Además, los Protocol Buffers y los co­m­pi­la­do­res Protobuf permiten una co­mu­ni­ca­ción que tra­s­cie­n­de las fronteras: los sistemas ope­ra­ti­vos di­fe­re­n­tes, los co­m­po­ne­n­tes dispares de es­tru­c­tu­ras cliente-servidor y los lenguajes de pro­gra­ma­ción di­fe­re­n­tes ya no re­pre­se­n­tan un problema. Así, un software escrito en C puede co­mu­ni­car­se con un software de Java, por ejemplo. Hoy en día, hay di­s­po­ni­bles co­m­pi­la­do­res Protobuf para un gran número de lenguajes, p. ej., para C#, C++, Go, Objective-C, Java, Python, Node.js, Android Java, Swift, Ruby y PHP.

La fle­xi­bi­li­dad de gRPC re­pre­se­n­ta otra ventaja. También se puede usar para el in­te­r­ca­m­bio de datos de mi­cro­se­r­vi­cios o de apli­ca­cio­nes móviles que comparten sus datos con se­r­vi­do­res. Más ventajas: el protocolo permite la apli­ca­ción de te­c­no­lo­gías modernas de seguridad. gRPC cuenta con una au­te­n­ti­ca­ción integrada y fomenta el uso de SSL/TLS para la au­te­n­ti­ca­ción y la co­di­fi­ca­ción del in­te­r­ca­m­bio.

En la otra cara de la moneda, ac­tua­l­me­n­te, las pruebas de las in­te­r­fa­ces gRPC todavía cuentan con mucho margen de mejora. Los mensajes gRPC co­di­fi­ca­dos con Protobuf no son legibles sin ayuda técnica. Por lo tanto, al analizar el tráfico de datos y, sobre todo, en la lo­ca­li­za­ción y solución de errores (debug) hay que usar in­s­ta­n­cias adi­cio­na­les para tra­n­s­mi­tir el código de forma legible para detectar los errores. La in­te­r­co­ne­xión de es­tru­c­tu­ras cliente-servidor di­s­tri­bui­das implica más de­s­ve­n­ta­jas. Al conectar or­de­na­do­res a través de largas di­s­ta­n­cias, gRPC está mucho más expuesto que un sistema local. Depende de una red estable y potente y de que la red, el tráfico de datos, los pro­to­co­los de tra­n­s­mi­sión y el cliente y el servidor no se co­n­vie­r­tan en presa fácil de los hackers. Otra de­s­ve­n­ta­ja es que gRPC no es co­m­pa­ti­ble con el mu­l­ti­ca­s­ti­ng.

Co­m­pa­ra­ti­va entre gRPC y REST

Gracias a sus ventajas, gRPC re­pre­se­n­ta una al­te­r­na­ti­va co­m­pe­te­n­te a REST (Re­pre­se­n­ta­tio­nal State Transfer). REST es es­pe­cia­l­me­n­te adecuado para servicios más sencillos, mientras que gRPC de­sa­rro­lla todo su potencial en las in­te­r­fa­ces complejas (API). Por norma general, para el in­te­r­ca­m­bio de datos entre apli­ca­cio­nes, REST usa el formato de datos JSON, un formato con base textual, por lo que supone una gran carga para los recursos de la red.

El sistema gRPC, en cambio, es capaz de organizar un flujo de datos mucho más compacto gracias a los Protocol Buffers y HTTP/2. De esta manera, el espacio de memoria requerido para la se­ria­li­za­ción y bi­na­ri­za­ción se reduce en casi un 70 por ciento en co­m­pa­ra­ción con, por ejemplo, el sistema JSON. Además, el streaming bi­di­re­c­cio­nal, que funciona sin generar bloqueos en el in­te­r­ca­m­bio de datos, aporta enormes ventajas de potencia y velocidad en co­m­pa­ra­ción con REST.

Ac­tua­l­me­n­te, su coope­ra­ción con apli­ca­cio­nes web todavía deja mucho que desear, ya que no suelen estar op­ti­mi­za­das para el uso de búferes de registro, el paradigma “contrato primero” ca­ra­c­te­rí­s­ti­co de gRPC para el que sí están op­ti­mi­za­das las API Contract First del framework gRPC. Uno de los grandes problemas del trabajo conjunto con apli­ca­cio­nes web es que aún no es posible acceder a un servicio gRPC di­re­c­ta­me­n­te desde un navegador. REST no cuenta con estas de­s­ve­n­ta­jas, ya que, en co­n­tra­po­si­ción al protocolo HTTP/2, más moderno, HTTP es co­m­pa­ti­ble con todos los na­ve­ga­do­res, si bien es cierto que este co­n­tra­tie­m­po se puede compensar con un esfuerzo asumible, de manera que se puede usar el mismo servicio para una apli­ca­ción web y para una apli­ca­ción móvil. Una opción viable en este ámbito es gRPC-Web. Los de­sa­rro­lla­do­res gRPC siguen tra­ba­ja­n­do para encontrar más so­lu­cio­nes que faciliten la co­la­bo­ra­ción de gRPC con he­rra­mie­n­tas basadas en la web.

¿En qué casos se usa gRPC?

El sistema gRPC es es­pe­cia­l­me­n­te adecuado para una co­mu­ni­ca­ción eficiente entre procesos en es­tru­c­tu­ras cliente-servidor di­s­tri­bui­das que busquen una latencia baja y un flujo elevado de datos y mensajes. gRPC se usa con fre­cue­n­cia en y entre centros de datos alejados para conectar servicios o mi­cro­se­r­vi­cios entre sí. Como las he­rra­mie­n­tas gRPC son co­m­pa­ti­bles con los lenguajes de de­sa­rro­llo más comunes, es muy frecuente que se usen en entornos mu­l­ti­li­n­gües.

La velocidad, la efi­cie­n­cia y su carácter mu­l­ti­li­n­güe favorecen el uso de gRPC en el ámbito móvil y la co­mu­ni­ca­ción con apli­ca­cio­nes. El gRPC regula, sobre todo, el último tramo del pro­ce­sa­mie­n­to di­s­tri­bui­do de datos, ya que conecta los di­s­po­si­ti­vos, las apli­ca­cio­nes móviles y los na­ve­ga­do­res con servicios backend.

Además, el potente streaming a través de HTTP/2 lo pre­de­s­ti­na para la co­mu­ni­ca­ción punto a punto en tiempo real. El Internet of things y la domótica se be­ne­fi­cian de este pro­ce­di­mie­n­to re­s­pe­tuo­so con los recursos, ya que cada vez se ocupa más de la co­mu­ni­ca­ción de clientes de bajos recursos. Debido a su potencia y dado que es fácil de de­sa­rro­llar, esta te­c­no­lo­gía de co­mu­ni­ca­ción podría de­sem­pe­ñar un papel destacado en la nube en el futuro y co­n­tra­rre­s­tar, así, la hegemonía actual de REST. En la ac­tua­li­dad, gRPC también se maneja como al­te­r­na­ti­va al XML (Ex­te­n­si­ble Markup Language).

Nota

El XML es un formato de uso frecuente para in­te­r­ca­m­biar datos o guardar in­fo­r­ma­ción de manera es­tru­c­tu­ra­da.

Ir al menú principal