Hoy en día todo el mundo está familiarizado con API REST y la inmensa mayoría desarrolla sus aplicaciones pensando en una comunicación HTTP de este tipo entre los diferentes servicios implicados.
Hace varios años surgió una nueva perspectiva para trabajar dentro del paradigma cliente/servidor y no es otra que gRPC. Desde entonces, aunque muy lentamente, muchas compañías y desarrolladores han ido sumergiéndose en este nuevo API.
Pero… ¿Qué es gRPC?
gRPC en un proyecto creado por Google basado en un sistema de comunicación RPC (Remote Procedure Call).
Aunque actualmente gRPC es un proyecto Open Source y que forma parte de la Cloud Native Computation Foundation, inicialmente fue creado por la empresa Google para uso interno y al que denominaba Proyecto Protocol Buffers.
El objetivo de la compañía de Mountain View no era otra que mejorar la comunicación entre sus diferentes aplicaciones y servicios, ya que la mejora en rendimiento y tiempos de respuesta que ofrecía gRPC era superior al ya existente REST.
No sería hasta el año 2015 cuando Google publica gRPC como un proyecto Open Source. Sin embargo, a pesar de que lleva ya varios años en el mercado, gRPC sigue siendo una plataforma o protocolo sin explorar por muchas compañías y usuarios.
Aun así, gracias a la aportación de la comunidad de desarrolladores, ya da soporte a numerosos lenguajes de programación (Java, NodeJS, Go, Python, etc.), por lo que la integración en las diferentes aplicaciones existentes o futuras es mucho más sencilla.
La orientación principal para crear un API de este tipo es introducirlo en un ecosistema de microservicios y servicios distribuidos ya que ofrecen un gran rendimiento en escalabilidad y por su baja latencia.
Además, es un sistema de comunicación entre servicios basado en HTTP/2 que soporta Streaming bidireccional y es mucho más rápido y eficiente que otros servicios de comunicación.
¿Cómo se trabaja con gRPC?
gRPC está basado en un sistema de comunicación RPC y, por tanto, la forma en la que trabaja es bastante diferente a lo que ya conocemos de otras API’s.
Un sistema RPC es capaz de realizar una petición desde una aplicación cliente a un servicio que esté definido en un servidor (en el mismo o en diferente servidor) funcionando como si se tratase de una llamada local.
Se trabaja principalmente con servicios y mensajes. Los servicios son elementos que contienen los métodos RPC y que proporcionan la capacidad de comunicación con otros servicios y los mensajes son básicamente los elementos con información que viajan desde cliente al servidor y viceversa.
La definición de estos servicios y mensajes se realiza mediante el lenguaje Protocol Buffers o Protobuf. Este lenguaje también creado por Google (de ahí su nombre original) utilizan un protocolo específico para el serializado y deserializado de la información.
- Definición de un servicio con lenguaje Protobuf:
- Definición de un mensaje con lenguaje Protobuf:
Ventajas más significativas de gRPC
La creación de gRPC y su posterior uso por parte de Google y de otras importantes compañías y usuarios se debe a sus principales bondades:
Rendimiento:
Quizás sea el principal motivo por el que los usuarios pueden pensar en cambiar a gRPC. Proporciona velocidad y baja latencia a la hora de comunicar servicios cliente/servidor, por lo que mejora muchísimo los tiempos de respuesta y la experiencia de usuario.
Además, la información viaja serializada y en formato binario, ocupando un espacio mucho menor que si fuera a través de un servicio REST mediante formato JSON. Esto beneficia mucho para uso de aplicaciones móviles donde la velocidad de conexión es menor y se puede incrementar mucho el tiempo de respuesta.
Mejora en el streaming:
En este caso gRPC permite todas las alternativas posibles para el streaming de información:
- Sin streaming
- Streaming unidireccional de servidor a cliente
- Streaming unidireccional de cliente a servidor
- Streaming bidireccional.
Estrategia API First:
En la creación de API’s es fundamental la creación de un API robusta y que permita la perfecta comunicación entre cliente y servidor, de tal manera, que cada uno de ellos, disponga de toda la información que se debe mandar y que va a recibir.
Aunque la estrategia API First es algo opcional que ya puede ser utilizado en otras API’s como puede ser REST, en el caso de gRPC es algo intrínseco y obligatorio desde el principio.
Para la creación de servicios y mensajes, se define el API a través de un fichero proto (.proto) y es después cuando gRPC autogenera las clases bases de servicios y mensajes a partir de esa definición. De esta forma, se crea desde el primer momento un contrato entre cliente y servidor que ambos deberán cumplir para no romper el API.
Inconvenientes de gRPC
A pesar de que gRPC nos proporciona muchas facilidades y beneficios para su uso, también tiene una serie de desventajas que hacen de uso algo más complejo para algunos aplicativos o usuarios.
Legibilidad por parte del usuario:
A diferencia del API REST que utiliza el formato JSON para la transferencia de información mediante texto plano, gRPC utiliza ficheros binarios serializados por lo que por un lado es un beneficio, también es un inconveniente si se quiere utilizar esa información para hacer debug o detectar posibles problemas o errores en la comunicación entre aplicaciones.
Limitación con navegadores:
Actualmente no es posible la comunicación directa entre los navegadores del mercado y gRPC, ya que como sabemos, gRPC utiliza el protocolo HTTP/2 y lo exploradores actuales no proporcionan un nivel de control suficiente sobre este protocolo para admitir un cliente gRPC.
Aun así, existen varios métodos para realizar la comunicación del navegador con servicio gRPC:
- gRPC-Web: tecnología suplementaria a gRPC que soluciona el problema de compatibilidad.
- Crear API REST automáticamente desde servicios gRPC: esto es posible mediante la inclusión de anotaciones de los ficheros de definición protos.
Comparativa gRPC y REST
A continuación, se muestran las principales bondades y diferencias entre el los API’s gRPC y REST:
Uso de gRPC en grandes compañías
A pesar de que gRPC tiene muchas bondades sobre el papel, no son todavía muchas compañías importantes las han empezado a hacer un uso considerable de este API.
Las principales compañías que ha expuesto abiertamente que usan gRPC son:
- Netflix
- Square
- CISCO
- Juniper Networks
El principal caso de éxito, además de la originaria Google es la compañía de streaming Netflix. Hace unos años identificaron que con el aumento de usuarios de la plataforma y de contenidos, empezaron a detectar problemas de rendimiento y sobre todo en los tiempos de respuesta, que se traducían en una mala experiencia de usuario. Con la introducción de gRPC consiguieron mejorar los tiempos de respuesta gracias a su baja latencia y eso se tradujo en beneficio para el usuario final.
Otras compañías importantes, como Spotify, siguen apostando por la definición de API’s mediante REST.
En resumen
Se ha podido comprobar que este “nuevo” marco para la creación de API’s puede proporcionar muchos beneficios a los usuarios y a las empresas en cuanto a rendimiento, tiempos de respuesta, baja latencia, etc. Pero también tiene sus inconvenientes que pueden hacer echarse para atrás a muchos otros, como pueden ser la baja compatibilidad con los navegadores o la dificultad de mantenimiento y debug por su sistema de transferencia de información binaria.
En comparación con REST es posible que sea una forma de comunicación más rápida, aunque quizás más orientada al tema de microservicios y sistemas distribuidos dentro de un PaaS. Sin embargo, para una integración cliente/servidor desde frontales web, aplicaciones móviles, etc. la comunicación y puesta en marcha con REST es mucho más sencilla y rápida de hacer.
Aun así, es importante que cada usuario analice, haga alguna prueba de concepto y de rendimiento para ver qué API es la más adecuada para cada caso de uso.
Y tú, ¿con cuál te quedas?
