Nivel técnico del artículo

Este juramento de unión, sacado de la novela de Los tres mosqueteros de Alejandro Dumas, me ha parecido la mejor manera de definir lo que es GraphQL.

¿Qué es GraphQL?

Es un lenguaje de consultas de APIs preparado para interpretar una consulta dada una cadena con muchas similitudes a un objeto JSON, y que nos retorna los datos solicitados.

Consta de dos partes, una en la que definimos el esquema de la petición, y otra en la que mediante un Resolver ejecutamos la lógica de la petición solicitada, devolviendo los campos requeridos.

Ejemplo de esquema de petición con su consiguiente Resolver:

var queryType = graphql.NewObject(
graphql.ObjectConfig{
Name: "Query",
Fields: graphql.Fields{
/* Get (read) single project
http://localhost:8080/proxy?query={absint(project:"url"){wcet,log}}
*/
"absint": &graphql.Field{
Type: absintType,
Description: "Get gitlab project",
Args: graphql.FieldConfigArgument{
"project": &graphql.ArgumentConfig{
Type: graphql.String,
},
},
Resolve: func(p graphql.ResolveParams) (interface{}, error) {
return resolveWCET(p)
},
},
},
})

Descripción del problema

En el proyecto Aquas, surgió la necesidad de integrar una herramienta de terceros para ejecutar diversos cálculos y análisis, como es el caso del programa Absint.

Nuestro frontend debía de hacer una petición, pasando como parámetro la url de un repositorio de Gitlab, respositorio que contenía un ejecutable y un fichero de configuración en donde se detallaban las características del análisis. Ejecutar el análisis, generar un archivo de reporte y retornar el valor de WCET (Worst Case Execution Time) al frontend.

En un principio, la implementación de esta integración iba a tener su sitio más lógico, esto es, el backend, pero esto planteaba ciertos inconvenientes en el contexto del proyecto. El primero de ellos es la naturaleza propia del backend, un backend bastante dummy por decirlo de alguna manera (ya que la lógica de nuestro proyecto recae mayormente en el frontend), que sólo se encarga de la autenticación y de los diversos CRUD de los recursos que necesita el frontend. Otro de ellos es la necesidad de que en un futuro inmediato fuera necesario integrar otros servicios de terceros, que podían ser desde programas como el caso de Absint a APIs de terceros. Toda estas características hacía que chirriara algo esta estructura, puesto que añadía bastante complejidad y dependencias a nuestro backend.

Por ello, surgió la idea de usar GraphQL, un lenguaje de consulta de APIs para unificar las llamadas y las respuestas de todos estos servicios.

GraphQL consulta API

Algunas de las ventajas de usar GraphQL:

    • La API de GraphQL tiene un esquema fuertemente tipado:
      Este esquema tiene la ventaja de que nos documenta tanto los argumentos como las diferentes operaciones que podemos realizar (qué consultas, mutaciones y suscripciones). Esto nos puede aliviar de bastante trabajo, tanto del lado del desarrollo de dicha API, como de consumidor, ya que no tenemos que emplear nuestro tiempo en documentar o en trabajar con documentación deprecada.
    • Pide lo que necesites, y cuando lo necesites:
      Otra de las ventajas de utilizar GraphQL, es que podemos solicitar sólo los campos que necesitemos, sin tener que codificar nada.
      Por ejemplo, en el caso de la integración con Absint, se decidió incorporar la opción de que el usuario pudiera descargarse el log de la operación, por tanto se definió la siguiente estructura:

{
absint {
wcet
log
}
}

GraphQL Log

Por tanto, si no necesitamos el log de la operación podemos omitir dicho campo en la petición y sólo solicitar el valor de wcet, de esta manera, nos ahorramos bastante tiempo en devolver la respuesta y mejora notablemente la performance. Puesto que ya no devolvemos el fichero del log, con el consiguiente ahorro de tamaño en la respuesta.

Ejemplo de petición:
http://localhost:8080/proxy?query={absint(project:"url"){wcet,log}}

La respuesta a la petición con el log pesó 35 kb, mientras que la otra tan sólo 175 bytes.
Esto parece una cosa menor, pero tiene mucha importancia.

  • Un único endpoint:
    Todos los que hemos trabajado con API’s REST hemos tenido que lidiar con multitud de endpoints y de verbos HTTP para describir nuestras necesidades, pero no siempre es posible.Por ejemplo, es común que para conseguir una descripción maestro-detalle de un recurso tengamos que hacer más de una petición.Con GraphQL esto no es necesario, ya que con los dos puntos anteriores nos ahorramos todo esto, definiendo el esquema y pidiendo sólo los datos que necesitemos.
  • Integrar API’s de terceros:
    Con GraphQL podremos integrar llamadas a API’s externas o a microservicios de una forma sencilla, unificando tanto la petición como la respuesta, y esto, para el frontend es una enorme ventaja.En uno de los proyectos en los que trabajé hace un tiempo nos vimos en la tesitura de tener que integrar varias peticiones tanto a microservicios propios, como a API’s externas. Cada uno de estos servicios tenía su propia estructura para pedir las cosas y también cada uno de estos servicios respondía cada uno en un formato distinto. Imaginad tener que lidiar con todo esto del lado de frontend, ¿a qué a nadie le gustaría?

 

En resumen, GraphQL es un nuevo actor en el clásico ecosistema backend-frontend, que nos va a ayudar a intermediar entre ellos y con otros servicios externos. Nos va a ayudar a hacernos la vida un poco más fácil.

Ejemplo de proyecto con GraphQL para trastear: https://github.com/vgirbes/eur-converter-graphql

Bibliografía

Autor
Vicent Girbés
Vicente Girbés | Técnico de I+D en ITI
Categorías