Alternativas o complementos a API Rest

Owned by Onesait Platform
12/05/23
6 min read

  • Introducción

  • GraphQL

    • Principales características

    • Arquitectura

    • Como crear un servidor GraphQL con Spring Boot

    • Conclusiones GraphQL

  • gRPC

    • Principales características

    • Arquitectura

    • Pruebas realizadas

      • Entorno de pruebas

    • Resultados de las pruebas

    • Conclusiones gRPC

  • Conclusiones

Introducción

API Rest es la más común y extendida arquitectura de APIficación del sector, pero hay otras alternativas que merece la pena conocer, testear y valorar su aplicabilidad dependiendo de casos de usos y otros escenarios que se deben tener en cuenta.

Cuando hablamos de estas alternativas nos referimos principalmente a:

  • GraphQL

  • gRPC

Este análisis se ha basado principalmente en dos fuentes:

-        Artículos especializados y análisis externos

-        Análisis y experiencia propia basada en nuestro stack tecnolológico

 

GraphQL

GraphQL es un lenguaje de consulta en tiempo de ejecución para facilitar que en API los clientes consulten exactamente los datos que solicitan y nada más. 

Su diseño persigue ser rápido en ejecución, flexible y sencillo para los desarrolladores, permitiendo incluso que los desarrolladores creen consultas para extraer datos de varias fuentes en una sola llamada, y también flexibilidad para agregar campos o modificarlos, sin que esto afecte las consultas actuales.

Principales características

  • Tiene el control del recurso, reduciendo el ancho de banda y los tiempos, al acceder solo a los campos/información que se necesita en cada momento.

  • Puede trabajar sobre diferentes protocolos no sólo HTTP.

  • Se puede acceder a distintos recursos en una única llamada uniendo la respuesta.

  • Se elimina el concepto de endpoints, sustituyéndolo por tipos con los que indicar solo lo que se necesita.

  • El concepto de versionado de APIs desaparece, a partir de la flexibilidad de deprecar o añadir atributos sin cambiar la API.

  • Desacopla cualquier posibilidad de dependencia con el acceso a las bases de datos.

En GraphQL la pieza principal es el GraphQL Server:

  • Será el encargado de interpretar el esquema (análogo a OpenAPI3 en Rest API) y hacerlo cumplir.

  • Será el encargado de recoger las consultas y operaciones según marca la especificación.

  • Tendrá una consulta y una mutación denominadas permitiendo consultar simultáneamente diferentes repositorios.

Arquitectura

Como crear un servidor GraphQL con Spring Boot

Conclusiones GraphQL

  • Facilita en gran medida la integración Frontend y por lo tanto la creación de productos digitales.

  • Reduce las peticiones al backend desde el front customizandose las peticiones a través de queries

  • Reduce latencias frente a Rest API ya que no hace N peticiones y posteriormente compone el resultado a renderizar, sino que consigue todo en una sola llamada.

  • Además, es más eficiente que Rest en cuanto al trasiego y compresión de los datos y payload pero no respecto a gRPC, lo que impacta también la latencia.

  • En comparación a Rest API, no está tan extendido su uso y no dispone a su alrededor de estándares de especificación/documentación tan maduros y herramientas que faciliten el uso a través de una documentación clara, de gobierno y de la gestión de la seguridad.

 

gRPC

Es un protocolo RPC (Remote Procedure Call), el cual puede ser ejecutado sobre cualquier entorno para realizar conexiones o llamadas entre microservicios. Este protocolo fue creado por Google precisamente para la comunicación entre sus microservicios.

Principales características

  • Comunicación bidireccional y autenticación totalmente integrada con transporte basado en HTTP / 2.

  • Destaca el rendimiento, debido a su bajo consumo de CPU, ancho de banda,etc.

  • Ofrece JSON encondings y serialización con PROTO 3.

  • Genera automáticamente stubs idiomáticos de cliente y servidor para su servicio en una variedad de idiomas y plataformas como C, C++, C#, Go, Java, Node.js, Objective-C, PHP, Python, Ruby.

  • Autenticación incorporada soportando SSL.

 

En gRCP el Protocol Buffer o Protobuf, es clave. Es un lenguaje implementado, independiente de Google, y tiene un concepto muy análogo a lo que proporciona OpenAPI en APIRest en cuanto metodología API & Contract First.

Con protobuf se crea la espeficicación del servicio, tanto el nombre como sus métodos y sus mensajes. Para poder llevar a cabo su implementación, se realizará en un tipo de fichero con extensión .proto, de un modo lo más legible posible para el humano.

El objetivo de gRPC es que fuera multilenguaje y multiplataforma, por lo que teniendo en cuenta estas premisas, tan solo nos tendremos que preocupar de generar nuestro Protobuf y compilarlo en el lenguaje que necesitemos y obtener los artefactos que facilitarán la comunicación en el cliente y servidor en cuestión.

Arquitectura

 

Pruebas realizadas

Las pruebas se centran en 2 aspectos:

  • Acceso a base de datos continuo en el que los usuarios iran creando en una misma base de datos registros y obteniendolos de manera continua y compartida.

  • Gestión de hilos en trabajos con alta concurrencia y alto procesado.

Todas las pruebas se realizarán en 5 entornos diferentes, todas bajos SpringBoot:

  • gRPC (Netty-shaded)

  • Rest MVC HTTP/1.1 (Tomcat)

  • Rest MVC HTTP/2 (Tomcat)

  • Rest WebFlux HTTP/1.1 (Netty)

  • Rest WebFlux HTTP/2 (Netty)

Para utilizar todo el potencial de WebFlux la base de datos será MongoDB que dispone de repositorios reactivos para poder hacer las pruebas.

Para los casos de Rest se comparan tambien posibles diferencias sobre HTTP/1.1 y HTTP/2 aunque como la codificación sobre HTTP/2 la realizará nuestro Servlet, no deberá habrá diferencias en este tipo de servicios.

Entorno de pruebas

Para este test se va a utlizar un equipo con las siguientes especificaciones técnicas:

  • CPU: Ryzen 9 5900X (12 nucleos 24 hilos)

  • Ram: 32GB (8GBx4) 3600MHz CL18

  • SSD 480GB Kioxia

  • Sistema Operativo: Ubuntu 20.04.2 LTS

Las pruebas se realizarán en su totalidad en el mismo equipo (JMeter + Servicios + BBDD) por lo que se descartarán latencias.

Toda la monitorización se realizará con 3 herramientas:

  • Monitorización de linux (GUI)

  • glances (shell)

  • VisualVM (profiler JVM)

La herramienta de test será JMeter con el plugin de gRPC modificado ya que en esta versión, no se soporta un servidor en streaming.

Resultados de las pruebas

Ver informe.

Conclusiones gRPC

  • El proceso para los desarrolladores front y backend es arduo y poco amigable (a través de ficheros de interfaz Proto)

  • Es compatible con comunicaciones asíncronas y por lo tanto arquitecturas guiadas por eventos.

  • Aunque es cierto que en nuestras pruebas, condicionada por el stack tecnológico, no sale ganando con respecto a REST, seleccionado el stack tecnológico y el caso de uso adecuado, debería tener una gran performance y rendimiento en latencias al transferir la info en código binario (ahorra tiempo en conversiones y compresiones) cuando la información a transferir tiene un volumen importante. Para objetos pequeños la comparativa en tiempo no es tan significativa. Es un punto que debemos seguir analizando.

  • En comparación a Rest API, no está tan extendido su uso y no dispone a su alrededor de estándares de especificación/documentación tan maduros y herramientas que faciliten el uso a través de una documentación clara, de gobierno y de la gestión de la seguridad.

 

Conclusiones

  • Rest API es la mejor opción para escenarios de API economy, innovación y reutilización de servicios ya disponibles, ya que es el más ampliamente usado en el sector y diferencial en cuanto estándares de especificación (OpenAPI3), herramientas de ayuda al desarrollador, de gobierno y de gestión de la seguridad.

  •  Graphql en general es una gran alternativa, muy potente y positiva para los desarrollos con gran integración con canales (web, mobile…) y que tengan una necesidad de consultas y composiciones de las mismas muy grande para renderizar la información en pantalla, respecto a un pequeño número acciones de inserción y actualización de datos.

  • gRPC no es amigable para el desarrollador en cuanto a facilidades para desarrollo e integración, pero puede ser una alternativa interesante sistemas críticos y de muy baja latencia. En estos sistemas podría usarse para la integración interna de microsevicios/módulos.

En definitiva, en Onesait por la naturaleza de nuestros productos apostamos por Rest API como estándar de producto para la integración y apificación ágil, y se abren escenarios alternativos que conocemos como gRPC y Graphql, pero cuyo uso sería excepcional y solo tras un análisis conjunto y práctico de la idoneidad del mismo.