Antes de hablar de gRPC debemos conocer qué es RPC:
RPC por sus siglas en inglés significa: Llamada a procedimientos remotos. Esta es una técnica de comunicación ideada en los años 60, y en los años 80 se implementaron los primeros procesos.
Sin embargo, seguimos sin entender qué es eso de RPC. Bueno, cuando comenzó la internet, se hizo necesario poder intercambiar datos entre los diferentes computadores conectados a la red. Uno de los principales problemas era: ¿Cómo podemos ejecutar procedimientos en otros computadores desde nuestro computador?
Por ejemplo: En un computador tengo una aplicación que permite facturar, pero en otro computador está la aplicación de inventarios. Así que ¿Cómo podemos hacer que cuando se facture en un computador se registre el movimiento de inventarios en el otro computador?
Hoy en día es bastante natural para nosotros hablar de servicios web. Con estos servicios, hacemos una petición a un endpoint enviándole unos datos para que sean procesados y el servidor nos envía una respuesta del proceso. Pero antes del nacimiento de la web esto no era tan sencillo.
Así que lo ideal era poder hacer una ejecución de un procedimiento que se encontrara en otro PC, así fue como nació RPC.
Así pues, desde el computador A podemos llamar la función afectarInventario() que se encuentra en el computador B.
Como pueden ver, esta técnica es mucho más antigua que las actuales API Rest. Pero sigue siendo mucho más eficiente. El problema radica en que los dos computadores deben tener el mismo lenguaje de programación para poder ejecutarse, de lo contrario no se logrará.
Así que por eso Google creó gRPC, un framework que permite utilizar esas llamadas a procedimientos remotos entre prácticamente cualquier lenguaje de programación. gRPCgenera una capa de abstracción la cual nos evita esos dolores de cabeza para comunicar los diferentes lenguajes.
Así que dicho esto, con gRPC puedes tener una aplicación hecha en javascript en un computador A y otra aplicación hecha en Python en un computador B y podrás llamar desde JavaScript la función afectarInventario() que está escrita en Python.
¿Te suena genial!? Bueno, aún no he contado todas las ventajas.
Ahora imagina que en lugar de enviar texto plano (lo cual hacen todas las peticiones REST), puedas enviar datos binarios. Te lo explico mejor: Cuando haces una petición a una API Rest, tanto la petición como la respuesta son enviadas en texto plano. Si ya sé, estás enviando un JSON, pero ese JSON está enviándose como texto plano. Por lo tanto, si la respuesta del servidor es por ejemplo un objeto producto, este se verá más o menos así:
1{ 2 "product": { 3 "name": "Carro" 4 "model": 2020 5 } 6}
El anterior objeto JSON ocupa, quitándole los espacios, 41 bytes.
En gRPC se utilizan estructuras creadas con protobuffer. Si ya sé que es otro lenguaje que hay que aprender. Pero no es un lenguaje de programación, es un lenguaje que nos permite crear las estructuras que se van a enviar y recibir entre los lenguajes. Así que con protobuffer vamos a especificar cómo se envían y reciben los datos, por lo que nos ahorramos muchos datos que transferir. Una representación del ejemplo producto visto anterior mente, se puede entender como:
1Carro|2020
Ojo, no es exactamente como viaja la información, solo es una representación para entenderlo. Por lo tanto si ves en el anterior ejemplo se utilizan más o menos 9 bytes.
¿Notas la diferencia? ¿Por qué se puede lograr esto? Bueno, protobuffers envía los datos en un chorro de bits (unos y ceros) y sabe dónde inicia una propiedad y donde termina, por lo que no hay que identificarla con una etiqueta para entenderla. Por eso no necesitamos "name" ni "model", tampoco necesitamos identificar el objeto con "product" ni las llaves.
Protocolo de comunicación
Para poder enviar y recibir datos necesitamos un protocolo. Así que Google decidió que el protocolo que se utiliza para gRPC es HTTP 2. Este protocolo tiene muchas ventajas sobre el protocolo HTTP 1.1 que lleva muchos años en la industria, aquí te muestro cuales son:
[HTTP 2 vs HTTP 1.1]
| Caracteristicas | :HTTP 2: | :HTTP 1.1: |
|---|---|---|
| Transferencia | Binario | Texto |
| Headers | Comprimido | Texto plano |
| Multiplexing | Sí | No |
| Preticiones por conexión | Múltiples | 1 |
| Server push | Sí | No |
| Año de liberación | 2015 | 1997 |
Por estas razones fue que se eligió HTTP 2 como protocolo de comunicación. Transfieres los datos en formato binario, los headers los puedes comprimir, puedes hacer muchas peticiones en una sola conexión y puedes hacer server push.
Te dejo una imagen que nos muestra las diferencias en una petición normal a una página web:
Como puedes ver, una petición a una página web con el protocolo HTTP 1.1 necesita de una conexión por cada uno de los recursos. En el ejemplo, se ve que hay 3 conexiones, una para él .js otra para él .css y otra para él .png. Mientras que con el protocolo HTTP 2 solo se necesita de una conexión la cual nos devuelve los recursos necesitados. Esto mejora mucho el rendimiento al no tener que estar creando conexiones con el servidor.
Por lo tanto, el uso de gRPC se está popularizando mucho en la comunicación de los microservicios reemplazando el uso de peticiones REST.
Aún no podemos reemplazar las peticiones desde el navegador, ya que, al momento de escribir este artículo, aún los navegadores no soportan HTTP 2 de manera estándar.
Es hora de comenzar a investigar un poco cómo funciona este maravilloso framework.
Te dejo un link a un demo de HTTP 2: http://www.http2demo.io/
Antes de ir a gRPC debes saber crear APIs Rest, pero ¿sabes como crearla con buenas prácticas?
En este taller Alexys Lozada te enseña como crear correctamente una API Rest https://ed.team/cursos/api-rest
