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 was initially developed by Google as technology for implementing Remote Procedure Calls (RPCs). Today, gRPC is an incubated project of the Cloud Native Computing Foundation, which means it is used in production and is supported by a healthy pool of contributors.
To understand why Google developed gRPC, let’s briefly look at the timeline of API design.
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.
When the REST API architecture was introduced, it solved some of these challenges by providing a uniform way to access data and resources using generic HTTP methods like GET, POST, PUT, and DELETE. Although REST simplifies data access, the API often returns more metadata than is needed. REST APIs also require more information about the network (as in, where to send a request), so they are not as lightweight and efficient as RPCs.
By adopting newer technologies, gRPC updates the older RPC method to make it interoperable and more efficient. Today, this is an appealing choice when developing APIs for microservices architectures.
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 uses Protocol Buffers (or Protobufs) to define services and messages instead of XML or JSON. It’s a language-neutral mechanism for serializing structured messages that the services will send to each other.
Similar to the concept of the OpenAPI Specification for REST APIs, the API contract in gRPC is implemented in a .proto text file where a developer defines how they want the data to be structured. Then, a protoc compiler automatically compiles the .proto text file into any supported language. At runtime, the messages are compressed and sent in a binary format.
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.
Overall, this improves performance and reduces network utilization, which can be especially valuable in a busy microservices architecture. There are some limitations, however. HTTP/2 is not generally supported by modern web browsers, so you may need to use a reverse proxy like NGINX to deliver the application.
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 uses standard HTTP status codes for error handling. In contrast, gRPC offers much more granularity to define error status codes and ensure they are consistent. By default, the gRPC model is quite limited, but is most commonly extended using a richer error model developed by 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.
In summary, the choice between gRPC and REST depends on what you need to accomplish. gRPC provides an efficient, high-performance method for services to communicate in a distributed application. That said, it cannot be read directly by web browsers and other clients, and requires an API gateway or reverse proxy like NGINX to interact with front-end clients. It’s an excellent option for internal APIs that are part of an event-driven microservices architecture.
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.
gRPC APIs are also vulnerable to many of the most common API security threats. Standard API security practices like access control, encryption, and runtime protection are equally important in gRPC-based architectures.
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:
Ultimately, you should verify that your API gateway, web application firewall (WAF), and other API management and security tools are up to the task of protecting your gRPC applications and APIs in production. They should be able to import the .proto file for each service and use it to apply security protections for the gRPC application and APIs.
gRPC is gaining a lot of traction as a popular alternative for developers and large companies like Netflix and Lyft to use in microservices architectures. That said, gRPC isn’t a replacement for REST APIs nor is it an inherently better way to build APIs. gRPC is simply an alternative to consider if you are primarily building APIs for an internal microservices environment and need efficient, real-time communication.
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.