Antes de irme de vacaciones he estado jugando con GraphQL, leyendo mucho y practicando mucho sobre cómo puede ayudarme en mis aplicaciones. En este artículo quiero contarte qué es y cuáles son las diferencias frente a las APIs REST.
¿Qué es GraphQL?
Lo primero que cabe mencionar es que se trata de una especificación open source creada por Facebook, quien empezó a utilizarlo en 2012 en sus aplicaciones móviles y lo presentó por primera vez en 2015 en una conferencia de React.js, también de su invención, y ahora es mantenido por la comunidad. Si bien ha estado ligado desde el principio a React.js, se puede utilizar con cualquier lenguaje y tecnología. GitHub, Twitter, Pinterest y 20 minutos, entre otras, utilizan GraphQL. Su objetivo es servir los datos a través de una API.
GraphQL vs API REST
Lo primero que te preguntarás es qué te aporta GraphQL cuando ya veníamos trabajando con APIs REST. A grandes rasgos, la principal diferencia es que los front ends que utilizan GraphQL le dicen a la API qué es lo que quieren obtener en un formato específico, lo cual se conoce como declarative data fetching. La API es capaz de procesar dicha consulta y devuelve un JSON con el formato solicitado. Estas consultas pueden compararse con sentencias SQL y sólo se devuelven los datos que has pedido, ni más ni menos.
A diferencia de las APIs REST, en GraphQL solo hay un punto de entrada a la API, y solo utiliza GET y POST para todas las operaciones contra el endpoint. En lugar de haber modelos que representen las entidades que va a devolver la misma, hay algo llamado Schema, que es dónde se declara a qué se puede acceder a través de esta API. Además, este esquema sabe cómo recuperar los datos que solicita el cliente, a través de unas funciones llamadas resolvers. Por último, es la query la que determina qué debería de ocurrir en la API, no el Http Method o la URL, como ocurre en las APIs REST. De hecho, GraphQL no necesita de HTTP como transporte para funcionar.
¿Por qué aparece GraphQL?
En los últimos años, el número de aplicaciones que consumen los mismos datos ha crecido considerablemente. Ya no sólo pensamos en ofrecer al usuario la información a través de una página web, sino que además debemos tener en cuenta el asistente personal, la Smart TV, las aplicaciones móviles, etcétera.
Lo ideal es que para recuperar los mismos datos para diferentes front ends utilicemos APIs que, de forma homogénea, accedan a lo mismo, de tal forma que podamos simplificar los front ends, mejorar el control sobre nuestros datos, así como el mantenimiento de nuestro back end. Sin embargo, que todas las aplicaciones accedan a los mismos datos no significa que necesiten las mismas propiedades de los recursos que se estén solicitando, lo cual hace, muchas veces, que el cliente obtenga más datos de los que realmente necesita, y que las APIs REST no sean lo suficientemente flexibles en este sentido. Esto hace que sea necesario mejorar la carga de datos para todos estos dispositivos. GraphQL minimiza la cantidad de datos que deben ser transferidos, al ser capaz de adaptarse y mandar solo que el cliente le pide. Una API para dominarlos a todos.
Mejor con un ejemplo
Siempre es más fácil verlo con un ejemplo, así que voy a compararlo con una API REST para que entiendas bien la diferencia. El ejemplo que voy a utilizar es la API de Star Wars que puedes encontrar en SWAPI.co. Lo que voy a hacer es recuperar tanto en GraphQL como en esta API REST los mismos datos: Necesito el nombre de todas las películas donde ha aparecido Luke Skywalker y los personajes que aparecieron en ellas.
API REST
Lo primero que tendría que hacer es recuperar el recurso de Luke Skywalker a través de https://swapi.co/api/people/1, para saber en qué películas apareció. Para obtener el nombre de las películas, necesitamos acceder a cada una de ellas, utilizando el endpoint que se indica en el resultado de Luke:

Como ves, ha aparecido en unas cuantas, por lo que necesitaremos ir y volver del servidor tantas veces como películas haya.
Cuando accedes a cualquiera de ellas, comprobarás que para saber qué personajes aparecieron en cada una también tenemos que hacer la misma tarea.

Habría que entrar en cada uno de los recursos para recuperar el nombre.
Además, también es importante señalar que cada vez que hago cada una de estas consultas, aunque solo necesite el nombre del personaje, sus películas y el nombre de los personajes que salen en la misma, no tengo más opción que traerme el resto de propiedades que no necesito para nada, lo cual se conoce como over fetching. Por último, también será necesario componer el resultado final o bien ir montando poco a poco cada uno de los componentes con el fragmento del resultado que toque.
GraphQL
Para conseguir la misma información con GraphQL puedes hacerlo desde https://graphql.org/swapi-graphql, lo cual es un wrapper de la API anterior. En este caso, la única consulta que deberías lanzar para lograr nuestro objetivo sería la siguiente:
{
person(personID: 1){
name
filmConnection{
films{
title
characterConnection{
characters{
name
}
}
}
}
}
}
Dando como resultado un JSON con el mismo formato que le hemos pedido.

Fácil de ver la diferencia ¿verdad?
¿Entonces GraphQL reemplaza a las APIs REST?
La verdad es que hay diferentes opiniones al respecto pero, en mi opinión, la respuesta siempre es: depende. Nunca he visto que una sola tecnología sirva para todo, pero sí creo que es conveniente al menos conocerlas y valorarlas antes de comenzar cualquier proyecto. Aquí te dejo algunas de mis anotaciones:
- En GraphQL es más compleja la gestión de la caché, ya que en las APIs REST tienes diferentes endpoints donde puedes utilizar los parámetros en la URL, el método HTTP, etcétera para cachear. Sin embargo, existen alternativas a utilizar en este aspecto.
- Puedes tener problemas de rendimiento en las queries, ya que son
los desarrolladores del front endlas aplicaciones cliente las que deciden el formato de la consulta a lanzar. Sin embargo, esto mismo puede ocurrir en las APIs REST, no tanto en la complejidad de la consulta pero sí en el número de peticiones para conseguir el resultado. - Las APIs REST también son capaces de recibir qué campos queremos de vuelta a través de la implementación de JSON Schema.
- Las APIs REST también pueden utilizar queries si usas OData.
- GraphQL puede llegar a convertirse en una aplicación compleja de mantener si tiene que gestionar el acceso a muchos recursos, así que precaución.
- Es más fácil gestionar los errores HTTP en las APIs REST que en GraphQL, aunque la mayoría de los frameworks te ayudan con esta parte.
- La subida de ficheros no está contemplada como parte de GraphQL, por lo que será necesario utilizar una implementación a parte.
¡Saludos!