Posted: 27 May 2021 5 Tiempo de lectura

gRPC vs REST API

Repasemos un poco la historia. Con la popularización de la web se hizo cada vez más común resolver de una forma sencilla y escalable la comunicación entre aplicaciones independientes a través de la red, es decir, realizar un puente entre aplicaciones. Este puente es la API (Application Programming Interface), en cuya integración se usan diferentes protocolos para definir la sintaxis de los mensajes que se envían desde el cliente hasta el servidor.

Con el paso del tiempo, se han lanzado diferentes estilos de arquitectura API. Cada uno con sus propios estándares a la hora de intercambiar datos.  Y yace aquí el meollo de la cuestión, ¿Qué estilo es mejor?

Como se puede ver en la imagen, desde los 90 se han desarrollado diferentes protocolos; actualmente el protocolo más usado es el REST API. Comienza a ser usado a principios de los 2000, poco a poco ganándose a la comunidad por su fácil curva de aprendizaje y sus múltiples formatos soportados (XML, JSON, HTML, texto plano).

Aun así, en este mundo de las APIs dominado por REST se van abriendo camino otros protocolos como es el caso de gRPC.

gRPC, ¿qué es?

Es un sistema de llamada da procedimiento remoto (RPC) implementado por Google. Con este protocolo podremos desarrollar servicios basados en RPC y clientes que los consuman.

Los RPC funcionan de la siguiente manera: un cliente invoca un procedimiento remoto, serializa los parámetros y envía el mensaje al servidor. El servidor al recibir el mensaje, serializa el contenido, ejecuta el procedimiento y envía al cliente el resultado.

Introducidos los dos contendientes, pasemos a explicar y enfrentar sus características:

IDL (Interface Definition Language): Protobuf vs JSON

El gRPC usa como IDL de mensajes el Protobuf (Protocol buffer) de formato binario no legible por humanos, desarrollado por Google para permitir la serialización y deserialización de datos estructurados. El desarrollador decide como estructurar los datos definiéndolo en archivos .proto. Después el fichero deberá ser compilado vía protoc. Dando como resultado un archivo con una clase por cada mensaje que hayamos definido.

En REST el IDL de los mensajes es múltiple, pero el más extendido tanto en tutoriales como en manuales de mejores prácticas es el JSON. Los mensajes JSON se intercambian en un formato de texto legible por el usuario, lo que hace que de base el tamaño del mensaje sea mayor, usando más ancho de banda.

Protocolos de transferencia: HTTP/2 vs HTTP/1.1

gRPC usa el protocolo HTTP/2, más nuevo y ligero, manteniendo las premisas y paradigmas básicos de HTTP, pero eliminando las partes opcionales de HTTP/1.1. El HTTP/2 es binario ayudando en gran medida a reducir la complejidad del manejo de marcos en HTTP/1.1. La mejora principal del HTTP/2 es que usa flujos multiplexados, lo que quiere decir que una sola conexión TCP puede admitir muchas transmisiones bidireccionales.

Por otro lado, REST usa el protocolo HTTP/1.1 cuya definición es demasiado completa y grande. En parte a todas las partes opcionales. En los tiempos actuales en los que las páginas web cada vez tienen un mayor número de objetos, el HTTP/1.1 es su gran enemigo, puesto que necesita de un gran número de solicitudes HTTP, que aumenta la carga de los servidores y ralentiza los tiempos de carga, siendo pues sensible a la latencia.

Caso de uso gRPC: Netflix

Netflix hacía uso de REST API, pero para 2015 se identificaron una serie de puntos débiles que hacían que se dificultara el descubrimiento, comprensión y auditoría de las APIs disponibles en el ecosistema. Con este conocimiento Netflix hizo esfuerzos para construir su propia RPC, para después optar por usar gRPC. El impacto de este cambio se tradujo en una bajada de latencia en el servicio; además de una disminución de tiempo de comercialización de clientes.

Hoy en día, en Netflix, gran parte de la comunicación interna de servicio a servicio se ejecuta en gRPC.

Caso de uso REST API: Spotify

Desde sus comienzos, Spotify hace uso de la llamada Spotify Web API, basada en los simples principios de REST. Spotify elige este puente de comunicación por la facilidad y la legibilidad que tienen para las aplicaciones cliente de terceros, haciendo que cualquiera con una mínima experiencia en el desarrollo de APIs pueda conectar con su servicio.

Conclusiones

El gRPC es recomendado para su uso en microservicios o para integraciones de APIs internas gracias a que ofrece una mayor escalabilidad y una optimizada respuesta por su baja latencia en el envío de mensajes por el formato binario de HTTP/2.

Por otro lado, REST es recomendado para integraciones con clientes y APIs públicas, muy fácil de usar y con unas restricciones de protocolo sencillas de implementar, además JSON es un lenguaje fácilmente interpretable por el humano. También posee una gran comunidad detrás que alimenta la documentación y las buenas prácticas del método de comunicación. Como desventaja hay que recalcar que por su formato es más pesado que gRPC (pero para los casos de uso donde es recomendado no es un gran factor a tener en cuenta).

Como conclusión podemos decir que cada proyecto tiene unas necesidades y requisitos diferentes por lo que la arquitectura API elegida debería depender del uso que vaya a tener.

 

Autor del artículo

Sergio Díaz Miranda, senior specialist de Consultoría Tecnológica de Deloitte