Vamos a ver si el protocolo gRPC, que está surgiendo como una de las fuertes alternativas frente al servicio REST tradicional, puede mostrar todos los beneficios que la gente está reclamando
Si ya has estado en la industria tecnológica últimamente, sabes que gRPC se está convirtiendo en uno de los protocolos más populares para la integración entre componentes, principalmente microservicios, debido a sus beneficios en comparación con otras soluciones estándar como REST o SOAP.
Hay otras alternativas que también se están volviendo mucho más populares a diario, como GraphQL, pero el enfoque de hoy es en gRPC. Si deseas echar un vistazo a los beneficios de GraphQL, puedes ver el artículo que se muestra a continuación:
Entonces, ¿cuáles son los principales beneficios que generalmente se exponen respecto al uso de gRPC y por qué empresas como Netflix o Uber lo están utilizando?
- Mensajes ligeros
- Alto rendimiento
- Soporte para patrón de transmisión
Parece una buena alternativa de una versión renovada de la llamada a procedimiento remoto tradicional que se ha estado utilizando en los años 90, pero probémoslo en algunos casos de uso real para intentar medir los beneficios que todos están reclamando, especialmente en cuanto al rendimiento y la ligereza de los mensajes, así que decidí definir un escenario muy sencillo de un patrón de solicitud/respuesta entre dos aplicaciones y probarlas con una llamada REST normal y una llamada gRPC.
Pila Tecnológica
Vamos a usar TIBCO Flogo para crear la aplicación y utilizar un entorno visual sin código para simplificar la generación de la aplicación. Si deseas ver más en detalle sobre esta tecnología, por favor revisa el post a continuación:
Entonces, vamos a crear dos aplicaciones: La primera se activará en intervalos programados cada 100 ms y llamará usando gRPC a la segunda aplicación que simplemente devolverá los datos a la aplicación de llamada codificados de manera fija para evitar que cualquier otro sistema de terceros pueda impactar en la medición del rendimiento.
En cuanto a los datos que vamos a transmitir, será un enfoque simple de Hola Mundo. La primera aplicación enviará un nombre a la segunda aplicación que devolverá el “Hola, nombre, Esta es mi aplicación gRPC (o REST)” para poder imprimirlo en la consola.
Enfoque REST
A continuación se muestran las aplicaciones para el caso de prueba utilizando la tecnología TIBCO Flogo para definirlo:
Como puedes ver, es simple e intuitivo. Tenemos la primera aplicación activada por un Trigger y con una actividad de Invocación REST y luego un Mensaje de Registro para imprimir lo que se ha recibido. La segunda aplicación es aún más simple, solo expone la API REST y devuelve los datos codificados de manera fija.
Enfoque gRPC
El enfoque gRPC será un poco más difícil porque necesitamos crear la definición protobuf para el cliente y servidor gRPC. Así que comenzaremos con una definición simple del servicio Hello como puedes ver en la imagen a continuación:
Y basado en eso, podemos generar las diferentes aplicaciones tanto del cliente como del servidor de esta prueba simple:
Como puedes ver, las aplicaciones son muy similares a las de REST, solo cambiando un protocolo por el otro, y eso es una de las cosas increíbles de TIBCO Flogo, podemos tener una implementación simple sin conocer los detalles de los protocolos más nuevos pero obteniendo todas las ventajas que proporcionan.
Resultados de la Prueba
Después de 100 ejecuciones del servicio REST, estas son las métricas que pudimos obtener usando el exportador de Prometheus que proporciona la herramienta:
Así que tenemos alrededor de 4 ms para el flujo del cliente y 0.16 ms para el servicio REST en sí, por lo que ya son números bajos. ¿Realmente crees que una versión gRPC podría mejorarlo? Vamos a verlo. Aquí están las mismas métricas para 100 invocaciones del segundo flujo usando gRPC:
Como puedes ver, la mejora es impresionante incluso para un servicio simple que se ejecuta en localhost. El servicio gRPC tuvo métricas de 0.035 ms frente a los 0.159 que tenía la versión REST, una mejora del 77.98% frente a la API REST, esto es simplemente increíble… pero ¿qué pasa con el cliente? Pasó de 4.066 ms a 0.89 ms, lo que significa otra mejora del 78.1%.
Entonces, la lógica debería ser si esto se puede hacer con un servicio simple donde los datos intercambiados son prácticamente nada, ¿qué puede hacer cuando la carga útil es grande? las opciones son simplemente inimaginables…
Resumen
Probamos las cosas buenas que hemos escuchado en línea sobre el método gRPC que la mayoría de las tecnologías de vanguardia están utilizando hoy en día y hemos quedado impresionados solo con un escenario simple comparándolo con el rendimiento de una interfaz REST. Seguro que gRPC tiene sus contras como cualquier otra opción, pero en términos de rendimiento y optimización de mensajes, los datos hablan por sí mismos, es simplemente asombroso. ¡Mantente atento a nuevas pruebas sobre los beneficios de gRPC y también algunos de sus contras para intentar ver si podría ser una gran opción para tu próximo desarrollo!
