gRPC es un framework que implementa el paradigma RPC, es decir, Remote Procedure Call o llamada a procedimiento remoto. La idea fundamental es que podamos llamar a una función en nuestro código como si fuera local, con sus parámetros y tipo de retorno habituales, pero que esa función en realidad se ejecute en otro proceso, ya sea en la misma máquina o en un servidor remoto dentro de una red. Lo interesante es que el código que hace la llamada no se entera de que esa función se ejecuta en otro lugar; simplemente la invoca y recibe la respuesta como si fuera una función normal.
Si nos detenemos a pensar, esto suena muy parecido a lo que hacemos con las APIs REST, y en efecto, ambas tecnologías persiguen objetivos similares: permitir la comunicación entre servicios. Sin embargo, existen diferencias importantes en su arquitectura y funcionamiento. En REST, el foco está en los recursos, que suelen representarse con identificadores como URLs. Trabajamos con esos recursos enviando mensajes HTTP que incluyen un verbo que indica la acción que queremos realizar, como GET para obtener información, PUT para modificar o DELETE para eliminar.
Por otro lado, en RPC lo que importa son los procedimientos o métodos que queremos ejecutar. En lugar de centrarnos en recursos, definimos comandos o funciones que el servidor debe ejecutar. Por ejemplo, podríamos tener métodos como LIST ALL USERS para obtener todos los usuarios, GET USER BY ID para obtener un usuario específico, o CREATE USER para crear uno nuevo pasando parámetros como nombre de usuario y contraseña. Estos métodos pueden devolver datos, como una lista de usuarios o una clave que confirme la creación exitosa.
gRPC es una implementación concreta de RPC creada por Google y liberada como código abierto en 2015. Es un sistema neutral que puede integrarse con múltiples lenguajes de programación. Esto significa que podemos tener un servidor gRPC escrito en Go o PHP y un cliente que lo consuma desde una aplicación en JavaScript, Android (Java, Kotlin) o Dart, por ejemplo. Al igual que REST, mientras cliente y servidor hablen el mismo protocolo, el lenguaje de programación no es una barrera.
El núcleo de gRPC está en los archivos proto, que definen las interfaces del servicio RPC usando un lenguaje llamado protobuf. En estos archivos se especifican los métodos disponibles, sus parámetros y tipos de retorno, así como la estructura de los datos que se intercambian. Por ejemplo, si un método devuelve un usuario, el archivo proto describirá qué campos tiene ese objeto usuario.
Para usar gRPC en un lenguaje específico, contamos con compiladores que transforman el archivo proto en código fuente propio del lenguaje. Por ejemplo, el compilador para JavaScript genera un módulo que podemos importar, mientras que el de Go genera un archivo con las estructuras necesarias. Con este código generado, podemos implementar el servidor definiendo qué hace cada método cuando se recibe una llamada remota, o bien crear un cliente que establezca la conexión y envíe las solicitudes al servidor.
Además, es necesario incluir una biblioteca runtime que se encargue de manejar la comunicación de red, codificando y decodificando los mensajes en el formato binario que gRPC utiliza para transmitir la información.
En cuanto a cuándo usar gRPC, aunque técnicamente podríamos implementarlo en cualquier proyecto, no siempre es la mejor opción. Es importante evaluar las ventajas y desventajas según el contexto. gRPC transmite los mensajes en formato binario, lo que reduce el tamaño de los datos y mejora la eficiencia. Esto lo hace ideal para entornos con recursos limitados, como dispositivos IoT pequeños, o para servidores donde la velocidad de respuesta es crítica. También es muy útil cuando la red es lenta o inestable, como en conexiones por radio, satélite o incluso en comunicaciones espaciales, donde minimizar el tamaño y la latencia de los mensajes es vital.
Sin embargo, esta eficiencia tiene un coste: la depuración y el análisis de las comunicaciones son más complejos. Al ser binario, no podemos simplemente inspeccionar las cabeceras o abrir las peticiones en un navegador. Aunque existen herramientas específicas para probar y depurar APIs gRPC, como Postman, Insomnia o gRPCurl, la experiencia no es tan sencilla como con REST. Por eso, si la facilidad para inspeccionar y depurar las comunicaciones es una prioridad, REST puede ser una opción más adecuada.
En definitiva, gRPC nos ofrece un modelo potente y eficiente para la comunicación entre servicios, especialmente cuando la velocidad y el tamaño de los mensajes son críticos, pero debemos considerar cuidadosamente el contexto y las necesidades de nuestro proyecto para decidir si es la mejor herramienta para el trabajo.