🎯 gRPC ¿Qué es?

Este artículo te explica que es gRPC y como funciona. Si necesitas un tutorial, puedes ver como hacer un servicio gRPC utilizando Spring Boot y Java.

gRPC es un framework que permite ejecutar métodos que están alojados en una computadora remota o servidor y en el cliente recibir el dato resultante al ejecutar ese método en el servidor. Es una actualización del marco de trabajo RPC creado en los años 80 y que fue muy utilizado para la comunicación cliente-servidor. De RPC también han surgido otros protocolos como XML-RPC y este después sería SOAP. Entonces, se pudiera decir que RPC fue como el papá de los servicios web que hoy conocemos. Sin embargo, conforme se fue masificando su uso, empezaron a surgir inconvenientes. Originalmente, RPC establecia que se podía utilizar cualquier protocolo de aplicación, por ejemplo SMTP, para la procesar la ejecución del método.

Si lo prefieres, también puedes ver y escuchar que es gRPC en el video de mi canal de YouTube.

En 2015, Google libera gRPC, de ahí el significado de la g inicial. gRPC trabaja sobre HTTP/2 y utiliza el lenguaje protobuffers para definir los servicios y datos que un servicio gRPC tiene. La idea principal de RPC es que puedas llamar a un método que está en un servidor independientemente del lenguaje con que esté programado el cliente y el servidor, ambos pueden estar desarrollados en diferentes lenguajes de programación. Algunos de las compañias de mayor renombre que usan gRPC son Netflix, Cisco, Square y por supuesto, Google.

Probablemente conozcas mejor SOAP, por lo que vamos a hacer una comparación rápida entre SOAP y gRPC.

Algunas de las ventajas que tiene gRPC son ventajas heredadas de HTTP/2. Vamos a ver las formas de comunicación entre un cliente, el cual se llama stub, y un servidor que es donde se ejecuta el código. Recordemos que gRPC es una arquitectura cliente-servidor. 

Comunicación Unaria

Es cuando se establece la conexión entre el cliente y el servidor, se ejecuta el método y este regresa una respuesta al Stub. Al recibir la respuesta, el ciclo de comunicación se cierra. 

Stream unidireccional. 

El stream unidireccional puede ser un flujo de datos desde el stub hacia el servidor o desde el servidor hacia el stub. En el primero, el cliente envía múltiples peticiones pero el servidor solo va a enviar una respuesta al stub. En el segundo, el stub envía una petición y el servidor enviará múltiples respuestas. Por ejemplo, cuando subimos un archivo es un flujo de datos unidireccional del cliente al servidor o vemos un video de YouTube, que es flujo de datos unidireccional del servidor al cliente. 

Streaming bidireccional

En el streaming bidireccional, tanto el servidor como el stub estarán enviando respuestas y peticiones al mismo tiempo sin que el servidor espere una petición o el stub espere una respuesta, simplemente los datos fluyen entre ambos lados. 

Una de las desventajas más marcadas de gRPC es que el debug necesita de herramientas especializadas para ver los datos, ya que no es tan simple de leer como XML o JSON porque están codificados en binario y no en texto plano. Afortunadamente, Postman ya soporta la ejecución de gRPC importando el protobuff y convirtiendo la petición de JSON a binario y la respuesta de binario a JSON. También existe una herramienta de línea de comandos llamada grpcurl.

Protobuffer

Abajo vas a encontrar un ejemplo de un protobuffer, el cual contiene la definición de un servicio, sus métodos y los objetos de petición y respuesta de los métodos.

service HelloService {
  rpc SayHello (HelloRequest) returns (HelloResponse);
}

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
}

La primera linea (que empieza con service) se define el nombre del servicio gRPC que se va a crear. En este caso, el nombre del servicio es HelloService. La linea siguiente, que empieza con rpc, define un método con el nombre SayHello. Entre parentesis es el tipo de objeto que va a recibir la petición (HelloRequest) y despues de returns es el tipo de objeto que va a responder el método (HelloResponse). Las lineas posteriores que empiezan con message, es la definición de los objetos de petición y respuesta del metodo SayHello. Los parametros de cada uno de estos objetos tienen un tipo de dato (string) y un nombre (greeting, reply). Después tienen un número, ese número es el orden consecutivo del parámetro.

El protobuffer es utilizado por los compiladores del servidor y del stub para crear las interfaces que van a realizar la comunicación y ejecución del método en el servidor. Por ejemplo, si tu protobuff lo compilas con Java, la libreria de gRPC va a generar el código fuente necesario en tiempo de compilación para crear las interfaces. Puedes utilizar la misma interface para crear el servidor y el cliente. La interface puede estar en un paquete separado del servidor. Si necesitas crear un cliente para otro lenguaje, simplemente importa los archivos protobuffer al compilador de protobuffer en el lenguaje deseado y de igual manera, se va a crear el código fuente necesario. El compilador de protobuffer se llama protoc.

Conclusión

gRPC parece ser una buena alternativa para la comunicación cliente-servidor y ejecutar métodos alojados en otra computadora y que pueden ser ejecutados por un cliente (stub) sin importar su código. Sus ventajas heredadas de HTTP/2 son una alternativa para SOAP y que la transferencia de información se haga en binario lo hace más eficiente incluso de RESTful. Su implementación requiere un análisis profundo en el diseño de la arquitectura del software que se vaya a realizar.