Google Remote Procedure Call (gRPC) es un marco de código abierto de alto rendimiento para implementar API a través de HTTP/2. Está diseñado para facilitar a los desarrolladores la creación de aplicaciones distribuidas, especialmente cuando el código puede estar ejecutándose en diferentes máquinas.
gRPC fue desarrollado originalmente por Google como una tecnología para implementar llamadas a procedimientos remotos (RPC). Actualmente, es un proyecto incubado de la Cloud Native Computing Foundation, lo que refleja su uso consolidado en entornos de producción y el respaldo de una amplia comunidad de colaboradores.
Para entender por qué Google desarrolló gRPC, veamos brevemente la cronología del diseño de API.
Las llamadas a procedimientos remotos (RPC) son una de las formas más antiguas de diseñar y construir una API. Este enfoque permite escribir código como si se ejecutara en un ordenador local, aunque realmente esté invocando un servicio que opera en otra máquina, generalmente dentro de la misma red local.
En la práctica, este enfoque permite a los desarrolladores ejecutar acciones directas (como SendUserMessages o addEntry) sin preocuparse por los detalles de la red. Los mensajes RPC son ligeros y eficientes, pero están estrechamente vinculados al sistema subyacente, lo que puede dificultar su integración o modificación y aumentar el riesgo de exponer detalles internos del sistema.
Cuando se introdujo la arquitectura API REST, se resolvieron algunos de estos problemas al proporcionar una forma uniforme de acceder a datos y recursos mediante métodos HTTP genéricos como GET, POST, PUT y DELETE. Aunque REST simplifica el acceso a los datos, la API suele devolver más metadatos de los necesarios. Las API REST también requieren más información sobre la red (por ejemplo, dónde enviar una solicitud), por lo que no son tan ligeras y eficientes como las RPC.
Al adoptar tecnologías más recientes, gRPC actualiza el antiguo método RPC para hacerlo interoperable y más eficiente. Hoy en día, se trata de una opción atractiva a la hora de desarrollar API para arquitecturas de microservicios.
Algunas de las ventajas de gRPC son:
En general, gRPC ofrece un marco flexible y de alto rendimiento que resulta ideal para las comunicaciones entre servicios en arquitecturas de microservicios altamente distribuidas.
Las ventajas y beneficios del gRPC se derivan en gran medida de la adopción de dos tecnologías:
gRPC utiliza búferes de protocolo (o Protobufs) para definir servicios y mensajes en lugar de XML o JSON. Se trata de un mecanismo independiente del lenguaje para serializar mensajes estructurados que los servicios se enviarán entre sí.
De forma similar al concepto de la especificación OpenAPI para API REST, el contrato de API en gRPC se implementa en un archivo de texto .proto en el que un desarrollador define cómo desea que se estructuren los datos. A continuación, un compilador protoc compila automáticamente el archivo de texto .proto en cualquier lenguaje compatible. En tiempo de ejecución, los mensajes se comprimen y se envían en formato binario.
Esto ofrece dos ventajas fundamentales:
Tradicionalmente, las API REST utilizaban HTTP/1.1 como capa de transporte. Aunque las API REST también pueden entregarse a través de HTTP/2, el uso exclusivo de HTTP/2 por parte de gRPC introduce algunas ventajas clave. Una de estas ventajas es la capacidad de enviar comunicación utilizando binarios. Además, HTTP/2 admite la capacidad de procesar múltiples solicitudes en paralelo en lugar de gestionar una solicitud cada vez. La comunicación también es bidireccional, lo que significa que una única conexión puede enviar tanto solicitudes como respuestas al mismo tiempo.
En general, esto mejora el rendimiento y reduce la utilización de la red, lo que puede ser especialmente valioso en una arquitectura de microservicios ocupada. Sin embargo, hay algunas limitaciones. HTTP/2 no es generalmente compatible con los navegadores web modernos, por lo que puede que tenga que utilizar un proxy inverso como NGINX para entregar la aplicación.
Hoy en día, REST es el estilo de diseño de API más dominante, por lo que proporciona un punto de referencia útil para comparar con gRPC. Tanto REST como gRPC son enfoques válidos para construir APIs para aplicaciones web y microservicios, y uno no es necesariamente mejor que el otro. Dicho esto, es útil entender sus diferencias clave para elegir la mejor herramienta para el trabajo.
Algunas de las principales diferencias entre gRPC y REST entran dentro de estas categorías:
Aunque las API REST pueden aprovechar HTTP/2, los servicios RESTful utilizan tradicionalmente HTTP/1.1 basado en texto como capa de transporte. gRPC utiliza exclusivamente HTTP/2, un protocolo binario más eficiente y que permite funciones como la compresión de encabezados y la multiplexación a través de una única conexión TCP.
Las API REST suelen utilizar JSON como formato para enviar y recibir datos. Este formato, basado en texto, es fácil de leer, escribir y ampliamente compatible.. Las API gRPC utilizan Protobufs, que tienen un formato binario que proporciona una carga útil más pequeña y una interacción más rápida. Sin embargo, los Protobufs no son fácilmente legibles de forma directa.
Las API REST admiten un modelo de solicitud-respuesta con soporte limitado para streaming. Por el contrario, las API gRPC se entregan a través de HTTP/2 y admiten varios patrones de comunicación, incluidos Unary (solicitud-respuesta), streaming de servidor, streaming de cliente y streaming bidireccional.
REST es un modelo centrado en los recursos que admite métodos HTTP estándar como GET, POST, PUT y DELETE. Cada solicitud debe contener toda la información necesaria para procesarla. Además, el contrato de la API suele escribirse utilizando la especificación OpenAPI y la codificación del cliente y el servidor se trata como un paso independiente. Por el contrario, gRPC es un modelo centrado en los servicios en el que los mensajes y los servicios se definen en el archivo .proto, que puede utilizarse para generar código tanto para el cliente como para el servidor de la API.
REST puede ser más lento debido a su transmisión de datos basada en texto a través de HTTP/1.1. Cada solicitud requiere un protocolo TCP que puede introducir cierta latencia. gRPC admite múltiples flujos a través de HTTP/2, por lo que varios clientes pueden enviar varias solicitudes al mismo tiempo sin establecer una nueva conexión TCP. También aprovecha las características de HTTP/2, como la compresión de encabezados.
REST utiliza códigos de estado HTTP estándar para la gestión de errores. En cambio, gRPC ofrece mucha más granularidad para definir los códigos de estado de error y garantizar su coherencia. Por defecto, el modelo gRPC es bastante limitado, pero lo más habitual es ampliarlo utilizando un modelo de error más rico desarrollado por Google.
REST cuenta con un amplio soporte en prácticamente todos los lenguajes de programación, aunque no incluye funciones integradas para la generación de código, dejando esta tarea completamente en manos del desarrollador. Por otro lado, gRPC, gracias a su compilador protoc, ofrece generación de código nativa para múltiples lenguajes de programación.
En resumen, la elección entre gRPC y REST depende de lo que necesite conseguir. gRPC proporciona un método eficiente y de alto rendimiento para que los servicios se comuniquen en una aplicación distribuida. Dicho esto, no puede ser leído directamente por navegadores web y otros clientes, y requiere una puerta de enlace de API o un proxy inverso como NGINX para interactuar con clientes front-end. Es una opción excelente para API internas que forman parte de una arquitectura de microservicios basada en eventos.
REST, por su parte, está ampliamente adoptado y es compatible con prácticamente cualquier lenguaje. Es legible por humanos y máquinas, ya que los datos se intercambian utilizando JSON o XML. Además, tiene una curva de aprendizaje mucho menor para empezar y es compatible con muchos navegadores web, lo que lo hace ideal para API expuestas públicamente.
gRPC es una de las mejores opciones para la comunicación en arquitecturas de microservicios, gracias tanto a su alto rendimiento como a su flexibilidad en el soporte de múltiples lenguajes de programación. Los desarrolladores pueden crear y generar fácilmente clientes y servidores gRPC en su lenguaje preferido, simplificando la integración. Además, al utilizar un contrato API definido en formato binario, gRPC permite que los microservicios se comuniquen de manera eficiente e independiente del lenguaje en el que se hayan desarrollado.
Una de las arquitecturas de microservicios basadas en gRPC más comunes consiste en colocar una puerta de enlace de API delante de los microservicios y, a continuación, gestionar todas las comunicaciones internas a través de gRPC. La puerta de enlace de API gestiona las solicitudes entrantes procedentes de HTTP/1.1 y las envía a los microservicios como solicitudes gRPC a través de HTTP/2.
A medida que crece la adopción de gRPC, los desarrolladores y los equipos de operaciones de seguridad deben asegurarse de que existen soluciones de seguridad eficaces. Dado que los mensajes gRPC están en formato binario, pueden surgir problemas en dispositivos y herramientas que esperan ver comunicaciones basadas en ASCII.
Las API de gRPC también son vulnerables a muchas de las amenazas más comunes a la seguridad de las API. Las prácticas estándar de seguridad de las API, como el control de acceso, el cifrado y la protección en tiempo de ejecución, son igualmente importantes en las arquitecturas basadas en gRPC.
Las aplicaciones gRPC y las API requieren un enfoque holístico de la seguridad. Entre las mejores prácticas para asegurar las gRPC figuran las siguientes:
En última instancia, debe comprobar que su puerta de enlace de API, su cortafuegos de aplicaciones web (WAF) y otras herramientas de gestión y seguridad de API están a la altura de la tarea de proteger sus aplicaciones gRPC y API en producción. Deben ser capaces de importar el archivo .proto para cada servicio y utilizarlo para aplicar protecciones de seguridad para la aplicación gRPC y las API.
gRPC ha ganado tracción como una alternativa popular entre desarrolladores y grandes empresas como Netflix y Lyft para arquitecturas de microservicios. Sin embargo, no sustituye a las API REST ni es necesariamente una forma superior de construir API. Es, más bien, una opción para tener en cuenta cuando se desarrollan API para entornos internos de microservicios que requieren comunicación eficiente y en tiempo real.
De cara al futuro, es probable que gRPC siga ganando terreno en las aplicaciones nativas de la nube debido a sus ventajas de rendimiento y facilidad de desarrollo. Mientras tanto, los desarrolladores que necesiten exponer públicamente API seguirán utilizando REST en sus aplicaciones. REST también seguirá existiendo en los entornos cloud-native debido a su compatibilidad con versiones anteriores y su profunda integración con la infraestructura y las operaciones de API existentes.
NGINX proporciona una variedad de recursos gratuitos para apoyarlo en cualquier etapa de su recorrido con gRPC.