¿Qué es gRPC?

Google Remote Procedure Call (gRPC) es un framework de código abierto y alto rendimiento para implementar API mediante HTTP/2. Está diseñado para facilitar a los desarrolladores la creación de aplicaciones distribuidas, especialmente cuando el código puede ejecutarse en distintas máquinas.

gRPC fue desarrollado inicialmente por Google como una tecnología para implementar llamadas a procedimientos remotos (RPC). En la actualidad, gRPC es un proyecto en fase de incubación de la Cloud Native Computing Foundation, lo que significa que se utiliza en entornos de producción y cuenta con el respaldo de una sólida comunidad de colaboradores.

¿Por qué se creó gRPC?

Para entender por qué Google desarrolló gRPC, repasemos brevemente la evolución del diseño de las API.

RPC es una de las formas más antiguas de diseñar y crear una API. Las RPC permiten escribir código como si fuera a ejecutarse en un ordenador local, aunque en realidad se podría estar llamando a un servicio que se ejecuta en otra máquina (normalmente, en la red local).

En la práctica, esto permite a los desarrolladores utilizar acciones directas (como SendUserMessages, addEntry, etc.) sin tener que preocuparse por los detalles de la red. Los mensajes RPC son ligeros y eficientes, pero también están estrechamente vinculados al sistema subyacente. Esto dificulta su integración y modificación, y aumenta la probabilidad de que revelen detalles sobre el sistema.

Cuando se introdujo la arquitectura de 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.

¿Cuáles son las ventajas de gRPC?

Al adoptar tecnologías más recientes, gRPC moderniza el antiguo método RPC para mejorar su interoperabilidad y eficiencia. Hoy en día, es una opción atractiva a la hora de desarrollar API para arquitecturas de microservicios.

Algunas de las ventajas de gRPC son:

Rendimiento: gRPC utiliza HTTP/2 como protocolo de transporte y Protocol Buffers de forma predeterminada, lo que puede ofrecer un rendimiento superior al de la comunicación mediante REST y JSON.
Streaming – gRPC admite la transmisión de datos para arquitecturas basadas en eventos, como la transmisión desde el servidor, la transmisión desde el cliente y la transmisión bidireccional para enviar simultáneamente solicitudes del cliente y respuestas del servidor.
Interoperabilidad – gRPC es compatible con una amplia variedad de lenguajes de programación y ofrece generación de código integrada, incluidos C++, Java, Python, PHP, Go, Ruby, C#, Node.js y muchos más.
Seguridad – gRPC proporciona autenticación, rastreo, equilibrio de carga, y comprobaciones de estado configurables para mejorar la seguridad y la resiliencia.
Nativo de la nube – gRPC funciona bien con implementaciones basadas en contenedores y es compatible con tecnologías modernas en la nube como Kubernetes y Docker.

En general, gRPC ofrece un framework flexible y de alto rendimiento, ideal para la comunicación entre servicios en arquitecturas de microservicios altamente distribuidas.

Entender gRPC: conceptos básicos

Las ventajas y los beneficios de gRPC se derivan en gran medida de la adopción de dos tecnologías:

Protocol Buffers para estructurar mensajes
HTTP/2 como capa de transporte

Protocol Buffers para estructurar mensajes

gRPC utiliza Protocol Buffers (o Protobufs) para definir servicios y mensajes en lugar de XML o JSON. Es un mecanismo independiente del lenguaje para serializar los mensajes estructurados que los servicios se enviarán entre sí.

De forma similar al concepto de la especificación OpenAPI para las API REST, el contrato de API en gRPC se implementa en un archivo de texto .proto, donde el desarrollador define cómo quiere que se estructuren los datos. A continuación, un compilador protoc compila automáticamente el archivo de texto .proto en cualquiera de los lenguajes compatibles. Durante la ejecución, los mensajes se comprimen y se envían en formato binario.

Esto ofrece dos ventajas clave:

gRPC requiere menos recursos de CPU porque los datos se representan en formato binario, lo que reduce el tamaño de los mensajes.
El esquema está claramente definido para garantizar que los mensajes se intercambien sin problemas entre el cliente y el servidor, lo que reduce los errores.

HTTP/2 como capa de transporte

Tradicionalmente, las API REST utilizaban HTTP/1.1 como capa de transporte. Aunque las API REST también pueden funcionar sobre HTTP/2, el uso exclusivo de HTTP/2 por parte de gRPC aporta algunas ventajas clave. Una de ellas es la posibilidad de transmitir datos en formato binario. Además, HTTP/2 permite procesar varias solicitudes en paralelo, en lugar de gestionar una sola solicitud cada vez. La comunicación también es bidireccional, lo que significa que una única conexión puede enviar solicitudes y respuestas simultáneamente.

En general, esto mejora el rendimiento y reduce el uso de la red, lo que puede resultar especialmente útil en una arquitectura de microservicios con mucha actividad. Sin embargo, existen algunas limitaciones. Los navegadores web modernos no suelen ser compatibles con HTTP/2, por lo que puede que necesite utilizar un proxy inverso como NGINX para servir la aplicación.

gRPC frente a REST: una comparación

Hoy en día, REST es el estilo de diseño de API predominante, por lo que constituye un punto de referencia útil para compararlo con gRPC. Tanto REST como gRPC son enfoques válidos para crear API para aplicaciones web y microservicios, y ninguno es necesariamente mejor que el otro. Dicho esto, conviene conocer sus principales diferencias para elegir la herramienta más adecuada para cada caso.

Algunas de las principales diferencias entre gRPC y REST se engloban en estas categorías:

Protocolo
Formato de datos
Transmisión
Diseño de API
Rendimiento
Gestión de errores
Compatibilidad con idiomas

Protocolo

Aunque las API REST pueden aprovechar HTTP/2, los servicios RESTful han utilizado tradicionalmente HTTP/1.1, basado en texto, como capa de transporte. gRPC utiliza exclusivamente HTTP/2, un protocolo binario más eficiente que permite funciones como la compresión de cabeceras y la multiplexación a través de una única conexión TCP.

Formato de datos

Las API REST suelen utilizar JSON como formato de datos para enviar y recibir información. JSON está basado en texto, es fácil de leer y escribir y cuenta con una amplia compatibilidad. Las API gRPC utilizan Protobufs, un formato binario que permite reducir el tamaño de la carga útil y agilizar la interacción. Sin embargo, los Protobufs no se pueden leer fácilmente por sí solos.

Transmisión en streaming

Las API REST admiten un modelo de solicitud-respuesta con compatibilidad limitada con la transmisión en streaming. En cambio, las API gRPC se proporcionan a través de HTTP/2 y admiten varios patrones de comunicación, como el unario (solicitud-respuesta), el streaming desde el servidor, el streaming desde el cliente y el streaming bidireccional.

Diseño de API

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 redactarse utilizando la especificación OpenAPI, mientras que la programación del cliente y del servidor se considera un paso independiente. En cambio, gRPC es un modelo centrado en los servicios, en el que los mensajes y los servicios se definen en el archivo .proto. Este archivo puede utilizarse para generar código tanto para el cliente como para el servidor de la API.

Rendimiento

REST puede ser más lento debido a la transmisión de datos basada en texto a través de HTTP/1.1. Cada solicitud requiere un protocolo de enlace TCP, lo 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 funciones de HTTP/2 como la compresión de cabeceras.

Gestión de errores

REST utiliza códigos de estado HTTP estándar para gestionar los errores. En cambio, gRPC ofrece mucha más granularidad a la hora de definir códigos de estado de error y garantizar que sean coherentes. De forma predeterminada, el modelo de gRPC es bastante limitado, pero suele ampliarse mediante un modelo de errores más completo desarrollado por Google.

Compatibilidad con lenguajes

REST es ampliamente compatible con prácticamente todos los lenguajes, pero no ofrece funciones integradas de generación de código. La implementación queda totalmente en manos del desarrollador. Gracias a su compilador protoc, gRPC permite generar código nativo para múltiples lenguajes de programación.

¿Deberías usar gRPC en lugar de REST?

En resumen, la elección entre gRPC y REST depende de lo que necesite conseguir. gRPC ofrece un método eficiente y de alto rendimiento para que los servicios se comuniquen en una aplicación distribuida. Sin embargo, los navegadores web y otros clientes no pueden interpretarlo directamente, por lo que requiere una puerta de enlace de API o un proxy inverso como NGINX para interactuar con los clientes front-end. Es una opción excelente para las API internas que forman parte de una arquitectura de microservicios basada en eventos.

REST, por otro lado, está ampliamente adoptado y es compatible con prácticamente cualquier lenguaje. Es legible tanto por personas como por máquinas, ya que los datos se intercambian mediante JSON o XML. Además, su curva de aprendizaje inicial es mucho menor y es compatible con numerosos navegadores web, lo que lo convierte en una opción ideal para las API de acceso público.

Arquitectura de microservicios con gRPC

gRPC es una de las mejores opciones para la comunicación en una arquitectura de microservicios. Esto se debe en parte a su rendimiento, pero también a su flexibilidad en cuanto a la compatibilidad con distintos lenguajes. Los desarrolladores pueden crear y generar fácilmente clientes y servidores gRPC que se ejecuten en su lenguaje preferido. Dado que gRPC describe el contrato de la API en formato binario, los microservicios pueden comunicarse independientemente de los lenguajes utilizados para desarrollarlos.

Una de las arquitecturas de microservicios basadas en gRPC más habituales consiste en colocar una puerta de enlace de API delante de los microservicios y gestionar después todas las comunicaciones internas mediante gRPC. La puerta de enlace de API gestiona las solicitudes entrantes a través de HTTP/1.1 y las reenvía a los microservicios como solicitudes gRPC mediante HTTP/2.

Consideraciones de seguridad de gRPC

A medida que aumenta la adopción de gRPC, los desarrolladores y los equipos de operaciones de seguridad deben asegurarse de contar con soluciones de seguridad eficaces. Dado que los mensajes de gRPC están en formato binario, pueden surgir problemas con los dispositivos y las herramientas que esperan comunicaciones basadas en ASCII.

Las API de gRPC también son vulnerables a muchas de las amenazas más comunes para 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.

Recomendaciones de seguridad para gRPC

Las aplicaciones y las API de gRPC requieren un enfoque integral de la seguridad. Algunas de las prácticas recomendadas para proteger los servicios gRPC son:

Validación de esquemas: bloquee los ataques maliciosos verificando que cada campo del mensaje gRPC tenga el tipo correcto y el contenido esperado.
Enmascaramiento de datos – Enmascare o bloquee datos confidenciales, como números de tarjetas de crédito y números de la Seguridad Social, para evitar que salgan del sistema.
Límites de solicitudes – Aplique límites estrictos al tamaño y al número de solicitudes para evitar ataques de denegación de servicio (DoS) por agotamiento de recursos.
Control de acceso – Exija la autenticación y la autorización antes de conceder al cliente acceso al servicio.
Cifrado – Proteja los mensajes en tránsito mediante el protocolo de seguridad de la capa de transporte (TLS).

En última instancia, debes comprobar que tu puerta de enlace de API, cortafuegos de aplicaciones web (WAF) y las demás herramientas de gestión y seguridad de API sean capaces de proteger tus aplicaciones y API gRPC en producción. Deben poder importar el archivo .proto de cada servicio y utilizarlo para aplicar medidas de seguridad a la aplicación y las API gRPC.

Resumen

gRPC está ganando mucha popularidad como alternativa entre desarrolladores y grandes empresas como Netflix y Lyft para su uso en arquitecturas de microservicios. Dicho esto, gRPC no sustituye a las API REST ni es una forma intrínsecamente mejor de crear API. gRPC es simplemente una alternativa que conviene tener en cuenta si se crean principalmente API para un entorno interno de microservicios y se necesita una 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 gracias a sus ventajas de rendimiento y a su facilidad de desarrollo. Mientras tanto, los desarrolladores que necesiten exponer API públicamente seguirán utilizando REST en sus aplicaciones. REST también seguirá presente en los entornos nativos de la nube debido a su compatibilidad con versiones anteriores y a su profunda integración con la infraestructura y las operaciones de API existentes.

Contenido relacionado