Productos de datos con GraphQL
Fecha de la noticia: 25-05-2021
Cuando hablamos de infraestructuras, la base de nuestra civilización moderna se basa en hormigón y acero. Miremos donde miremos, las grandes estructuras cómo carreteras, edificios, coches, trenes y aviones están hechas de hormigón y metal. En el mundo digital, todo está hecho de datos y APIs. Desde que nos levantamos por la mañana y miramos nuestro móvil interactuamos con datos y APIs.
Introducción
Cuando revisamos nuestro email, nos preguntamos el tiempo que va a hacer o comprobamos nuestra ruta en coche, lo hacemos a través de aplicaciones (móviles, web o de escritorio) que hacen uso de las APIs para devolvernos los datos que solicitamos. Ya hemos hablado con anterioridad, largo y tendido de las APIs, a través de diversos contenidos donde hemos explicado, por ejemplo, cómo publicar datos abiertos utilizando este mecanismo o cómo garantizar que las Apis cumplen con determinadas especificaciones.
Las APIs son las interfaces mediante las cuales los programas informáticos hablan entre sí e intercambian información. El actual estándar absoluto de las APIs es la tecnología REST. Hace tiempo que REST sustituyó a SOAP como tecnología preferente para comunicar unas aplicaciones con otras a través de Internet. REST utiliza el protocolo HTTPs cómo medio de transporte para hacer preguntas y obtener respuestas. Por ejemplo, la app de AEMET, ejecuta una consulta vía REST utilizando HTTPs a través de Internet hacia los servidores de AEMET. Cuando los servidores de AEMET (lo que se conoce cómo la API de AEMET) recibe la consulta concreta, devuelve la información a nuestro móvil tal y cómo esté programado. Todo esto suele ocurrir muy rápido (en menos de un segundo habitualmente) y es inapreciable para nosotros.
Sin lugar a dudas la mayoría de los productos digitales se basan en API REST para su funcionamiento. Los productos de datos no son una excepción y la gran mayoría adoptan este estándar para su funcionamiento. Sin embargo, pese a la gran aceptación y flexibilidad de REST, éste, no es perfecto, y algunas de sus limitaciones impactan negativamente en el desarrollo de productos muy orientados a datos. Algunas de sus limitaciones más evidentes son:
- REST es todo o nada. Cuando se hace una consulta se obtiene el resultado íntegro que está programado. Por ejemplo, si se quiere consultar un usuario en una base de datos, normalmente se hace una llamada (al endpoint) de usuarios y se obtiene la lista completa de usuarios.
- REST, a menudo, requiere varias llamadas para obtener los datos deseados. Siguiendo con el ejemplo anterior, si se desea consultar el saldo de una cuenta bancaria de un usuario, es habitual, tener que realizar la llamada a la lista de usuarios, luego llamar a la lista de cuentas bancarias, cruzar estos dos resultados y, finalmente, llamar a la consulta de saldos con el usuario y su cuenta bancaria cómo parámetros de la consulta final.
- REST no está diseñado para gestionar fácilmente relaciones. En el ejemplo anterior veíamos cómo para obtener el resultado de una consulta relacionada hemos de hacer varios pasos secuenciales intermediando consultas parciales.
Para entender de forma sencilla la diferencia entre un una aplicación de IT orientada a servicios y otra orientada a datos, pongamos un ejemplo: cuándo se desarrolla una aplicación moderna con diferente funcionalidad, se suele hablar de un patrón de diseño orientado a servicios (service-oriented IT). Bajo este patrón, un servicio que permita a los usuarios iniciar sesión en el sistema, es un caso típico de integración entre servicios. Esta funcionalidad, típicamente, utiliza API REST cómo mecanismo de integración. Un ejemplo concreto son aquellas aplicaciones que nos permiten iniciar sesión en su servicio utilizando una cuenta de email o una red social. El caso de un servicio orientado a datos, es aquel en que el la aplicación, realiza una consulta al sistema con el objetivo principal de intercambiar datos. Por ejemplo, cuando solicitamos el tiempo promedio que un usuario ha estado navegando por una parte concreta de nuestra aplicación o web.
GraphQL
Cómo alternativa a REST y para superar estas limitaciones, en 2012 Facebook crea GraphQL. Por aquel entonces, Facebook lo usa de manera interna para sus propias consultas sobre la red social, pero en 2015, la compañía decide publicar el código fuente de este proyecto convirtiéndolo en un software Open Source.
La gran ventaja de GraphQL es la posibilidad de solicitar datos concretos, con independencia de cómo se organizan los datos en su origen. Los datos de origen pueden estar organizados (y almacenados) en una base de datos relacional, en un API REST en una base de datos NoSQL o en un objeto diseñado de forma específica, por ejemplo, el resultado de un algoritmo.
El aspecto que tiene una consulta en el lenguaje de GraphQL es de esta forma:
{
Bicicletas_Barcelona(district:1, type:”electric”){
Bike,
Street
}
Barcelona(district:1){
Bus,
Stop,
Lat,
Long
}
}
En el ejemplo anterior, partiendo de un conjunto de datos abiertos disponible en datos.gob.es, con GraphQL, seríamos capaces de combinar (en una sola consulta) los resultados de la localización de un parking urbano de bicicletas eléctricas en Barcelona junto con la posición de una parada de autobús cercana. El objetivo sería poder construir un producto de datos que sea capaz de planificar desplazamientos urbanos en medios de transporte sostenibles[1]. De la misma forma podríamos combinar múltiples fuentes de datos, por ejemplo, los datos abiertos sobre autobuses y movilidad del resto de ciudades de España. Tan solo tendríamos que incorporar estas nuevas fuentes de datos puesto que el modelo subyacente que devuelve las consultas sería muy similar.
Cómo se ve en la consulta, GraphQL es de naturaleza declarativa. Se utiliza el formato JSON para declarar de forma muy sencilla y clara qué es lo que se está solicitando al sistema.
Un ejemplo de GraphQL
Supongamos que tenemos una base de datos para gestionar un curso formativo. Es fácil pensar que en esa base de datos tengamos varias tablas con el registro de los alumnos, las asignaturas, las calificaciones, etc. Cuándo apificamos con REST esta base de datos, crearemos varios endpoints para consultar, los estudiantes, las asignaturas y las calificaciones. Cuándo queramos consultar los alumnos que son aptos en una asignatura concreta deberemos hacer varias llamadas consecutivas y nuestra aplicación deberá de encargarse de hacer los filtros correspondientes. El flujo lógico sería algo tal que así:
- Solicitamos la lista de alumnos.
- Solicitamos la lista de asignaturas.
- Cruzamos ambas listas y filtramos para la asignatura que deseamos comprobar.
- Solicitamos la lista de calificaciones para esa asignatura.
- Filtramos los alumnos por encima de una determinada calificación.
Cada una de estas llamadas tendrá un endpoint diferente del tipo:
Sin embargo, en GraphQL podemos realizar esta consulta en una sola llamada puesto que GraphQL permite consultar datos relacionados en una misma llamada.
En conclusión, GraphQL es una tecnología a tener muy en cuenta hoy en día cómo herramienta de integración con los sistemas de información. De forma general, se acepta que las APIs REST están más orientadas a la integración entre servicios de internet (por ejemplo un servicio de autenticación de un usuario) mientras que GraphQL está más orientada a la integración entre productos de datos (por ejemplo un comparador de precios en Internet). Todo apunta en este interesante debate entre integración de productos de TI versus los productos de datos, ambas tecnologías coexistirán en el futuro cercano.
[1] Esta consulta ha sido adaptada de su fuente original. Gracias a Ángel Garrido Román por su explicación detallada en su TFG 2018.
Contenido elaborado por Alejandro Alija,experto en Transformación Digital e Innovación.
Los contenidos y los puntos de vista reflejados en esta publicación son responsabilidad exclusiva de su autor.
