En el momento en el que tenemos que plantear un nuevo servicio web, tanto para un cliente que nos dé carta de libertad como un desarrollo propio tomamos la pronta decisión de utilizar un API REST por varios motivos: porque hoy en día es lo más común que utilizan los backends que ofrecen este tipo servicio, porque estamos acostumbrados a usarlo, porque todo el mundo que haya lidiado con el desarrollo web lo conoce y además conocemos las herramientas suficientes como afrontar cualquier desarrollo de la manera más rápida y eficaz posible.
Aquí es donde entra en juego GraphQL, nueva API desarrollada por Facebook, que nos brinda un nuevo mundo de posibilidades. Al ver las diferencias entre las dos, intento convencer a mis compañeros de que el futuro ya es presente, y es GraphQL. Por desgracia, estas han sido unas cuantas citas de lo que me he ido encontrando:
"Esto si lo ha desarrollado Facebook, funcionará sólo para React, ¿no?"
"¡Yo paso de GraphQL y más si es de Facebook!"
"Esto al final no deja de ser como una REST ¿Para qué estudiar GraphQL?"
"Creo que de momento puedo vivir con REST"
Desde mi punto de vista, este tipo de pensamientos nos lleva al estancamiento profesional si somos así de cerrados. ¡ES HORA DE APRENDER!
Lo mismo voy a hacer contigo, ¡Sí, la persona que está leyendo esto!, voy a tratar de convencerte con este artículo o con este vídeo que está justo aquí abajo (haciendo click en la imagen) para que a partir de ahora afrontes nuevos retos y uses GraphQL:
¿Cuál es la idea que hay detrás de las API REST y GraphQL? ¿Qué es lo que tienen en común?
Antes de enseñarte las diferencias, voy a mostrarte qué es lo que tienen en común:
En primera instancia, cuando hablamos de construir un servicio web basado en APIs se siguen estos enfoques:
- Ocupar un lugar en nuestro servidor para recibir peticiones HTTP por parte de cualquier cliente (web, mobile…).
- Exponer puntos de entrada para consultar o enviar datos. Tanto el caso de un API REST y GraphQL usan estos conceptos relacionados construyendo así un servicio web donde en ambos escenarios se ve influenciado en cómo nuestro cliente realiza consultas o qué es lo que necesita de este servicio.
- JSON es el tipo predeterminado de datos que se intercambian entre un cliente con el servicio, pero existe la posibilidad de implementar el intercambio de datos binarios, ficheros...
- Funcionan bajo cualquier lenguaje en el lado del servidor, como puede ser PHP, Scala, Node…
- Para frontend tienes total libertad de elegir la tecnología que quieras, no es que se te prohíba desarrollar una aplicación móvil con Swift, ni dejar de lado Angular y utilizar React, eso da igual. No deja de ser un cliente que envía peticiones HTTP a un servicio web.
- Son Stateless, es decir, no toma importancia sobre el cliente que lo está utilizando, no viene implementado un sistema de autentificación, no guardamos ningún dato del cliente, sólo se limita a recibir correctamente la petición y devolver al cliente el recurso que necesite o modificarlo. Todo lo anterior se puede implementar a posteriori en nuestro backend. Se han de utilizar estas APIs como una capa de nuestro servicio web para el intercambio de datos.
¡Ya basta! ¡Quiero ver las diferencias!
¡Está bien! ¡Está bien! Veamos cuales son las diferencias:
- La diferencia principal y más importante es que GraphQL no está tratando con recursos dedicados. Es más, todos los recursos se consideran más bien en su totalidad un conjunto de grafos conectados entre sí. Esto da lugar a que puedes adaptar tu consulta a las necesidades del cliente utilizando el lenguaje de consulta de GraphQL (basado en Schemas) describiendo lo que le gustaría tener como respuesta, así como combinar diferentes entidades (o tipos) en una consulta y qué atributos deben incluirse en la respuesta de cada nivel.
- Un API REST abraza el concepto de tener múltiples endpoints (puntos de entrada), por tanto, se van a exponer múltiples rutas de tu servicio web. En cambio un API GraphQL sólo va a exponer un único endpoint o ruta el cual suele recibir el nombre /graphql, aunque puedes asignarle el nombre que tu quieras.
- GraphQL soluciona el problema que tiene REST relacionado con el Over Fetching y Under Fetching, es decir, puede darse el caso que con un servicio RESTful sobren o nos falten datos. Cada endpoint tiene una estructura fija de datos que se van a devolver cada vez que se realice una petición. En el caso de Over Fetching hay situaciones en las que no necesitamos toda la información y acabamos ignorando muchos de los datos, lo cual es indicativo de que realmente no estamos siendo del todo eficientes. Este problema hace que tengamos una carga de datos más lenta y consumamos más ancho de banda, o en el caso de los móviles consumamos más datos. El Under Fetching se da cuando nos faltan datos y requiere de otra petición adicional que nos devuelva los datos que nos falta.
- Un API REST reacciona de diferentes formas dependiendo de los métodos HTTP existentes (GET, POST, PUT…). Un API GraphQL va a utilizar únicamente el método POST.
- GraphQL utiliza resolvers para recopilar los datos que solicita un cliente. Se puede medir el rendimiento para evitar cuellos de botella en el sistema.
- GraphQL integra la posibilidad de utilizar WebSockets.
- Un API REST tiene implementado el almacenamiento en caché para que el cliente evite volver a buscar estos recursos. GraphQL deja esa responsabilidad a los clientes o bien integrar manualmente un sistema de almacenamiento de caché. La única tecnología que he visto hasta ahora que brinda cierta compatibilidad es Relay
- Para el manejo de errores de un API REST nos basta con conocer el estado de la respuesta a través de los códigos de estado HTTP (HTTP status codes). En GraphQL obtendremos siempre una respuesta de código 200 (si el servidor responde correctamente), es decir, es una petición exitosa. El error lo obtendremos en la respuesta de la petición como un fallo en el procesado de la consulta. GraphQL recurre a esto ya que podemos lanzar más de una consulta a la vez, por tanto, algunas se resolverán correctamente y otras pueden fallar, pero no es motivo para cambiar el estado de la petición.
- GraphQL nos permite obtener información exacta de los datos que comúnmente se solicitan en el backend. A medida que el cliente especifica esta información, resulta más fácil entender el uso de los datos y su disponibilidad.
- El versionado de un API REST no es trivial, es decir, si necesitamos dar soporte a múltiples versiones normalmente significa crear nuevos endpoints. Esto causará más problemas y dolores de cabeza cuando es usado y además su mantenimiento será más costoso y puede dar lugar al llamado código spaghetti. Con GraphQL nos podemos ir olvidando, ya que se pueden añadir o eliminar campos sin romper la consulta. También existe la forma de excluirlos de la respuesta.
Para no alargar mucho este artículo y que no sea tan extenso, en futuros artículos se hablará de todos estos aspectos que diferencian GraphQL de REST: el comportamiento de estas dos APIs a la hora de enviar peticiones, cómo lidiar con el lenguaje basado en Schemas que utiliza GraphQL, así como construir un servidor bajo Node.js y cómo conectarse a una aplicación web.
Si quieres irle hincando el diente, te recomiendo estos sitios web:
Si quieres ver un ejemplo, pulsa aquí.
Conclusión
GraphQL arregla problemas que tiene un API REST a excepción del almacenamiento en caché que necesita ser controlado por el cliente o bien utilizar librerías externas que implemente dicha funcionalidad. Se centra más en la capacidad de desarrollo de APIs que se adecuen al tipo de uso según las necesidades del cliente, agiliza el desarrollo y cambios realizados en el cliente y su mantenimiento es menos costoso.
Si te ha gustado, ¡síguenos en Twitter para estar al día de nuevas entregas!