¿Qué es GraphQL?
4 minutos de lectura
Fecha: 18/8/2018
Siendo una tecnología en auge que podría cambiar el paradigma de comunicación entre cliente y servidor es interesante tener claro que es GraphQL.
En primer lugar, es importante decir que GraphQL no es ni un framework ni una librería, es una especificación.
Por lo que si estas pensando en que es un paquete de código desarrollado por un tercero que mañana podría desaparecer y atarte, no es del todo así…
Obviamente como es una especificación luego si que tendrás que usar una librería que lo implemente, pero lo mismo pasa en otros casos. Por ejemplo, hace tiempo Facebook sacó un patrón de diseño llamado Flux para manejar el estado de las aplicaciones, como tal flux es un conjunto de ideas, luego por ejemplo nació vuex que es una librería que implementa ese concepto para trabajar con vue.js.
Pues aquí pasó igual GraphQL es una especificación que también creo Facebook en 2012 para usarlo internamente en sus proyectos y que pasó a ser de código abierto en el 2015. Después tenemos distintos paquetes de código que lo implementan para distintos lenguajes.
Lo que define es una nueva API para realizar comunicaciones con el servidor.
Actualmente esta tarea se suele solventar usando la API REST, que es una definición para comunicarse con el servidor mediante protocolo HTTP usando sus verbos.
GraphQL se ha definido muchas veces como la evolución natural de REST, sin embargo hay que matizar que dicho así parece que lo sustituye y no es del todo así, es cierto que puede sustituirlo pero también pueden complementarse.
Digo esto para que no de tanto miedo comenzar a usarlo, no tienes porque dejar de usar REST si no te fías. De hecho, GraphQL podría ser una capa por encima de REST para simplificar las llamadas desde el front.
Pero claro, esto no es un motivo para que valores comenzar a usarlo, la pregunta importante no solo es que es, sino también que te aporta, y sobre todo que te aporta frente a REST que es lo que casi todo el mundo usa hoy.
Asi que voy a enumerar los motivos que me convencen.
Con un mismo endpoint podemos hacer distintas peticiones
Este es un asunto sin duda muy importante, ya que la dificultad para gestionar la información de esta manera se reduce mucho. La metodología de GraphQl es muchísimo más óptima que la de REST.
Para que nos entendamos, cuando usamos APIs de tipo REST cada endpoint (cada uri) representa un único recurso. Por ejemplo si piensas en un blog como este podemos entender por recurso los posts, de modo si quisieramos publicarlos en REST habría una uri para manipularlos que seguiría este esquema.
{protocolo}://{dominio o hostname}[:puerto (opcional)]/{ruta del recurso}?{consulta de filtrado}
En nuestro caso podemos pensar en algo de este estilo
http://oscarlijo.com/posts/125
En este caso bajo la ruta del recurso (que sería posts) podemos usar los verbos HTTP para hacer las operaciones CRUD del recurso.
Si usaramos el verbo GET y le añadimos el id 125 como vemos arriba estamos pidiendo que devuelva ese post en concreto por ejemplo.
Parece perfecto, muy sencillo de entender y facil de trabajar con él. Pero pensemos en este caso, cuando yo quiero pintar una entrada no solo necesito el contenido del post, necesito todo esto…
- El contenido del post
- La información del usuario que escribió esta entrada
- Los comentarios asociados a esta entrada
Obviamente tanto los posts, los usuarios y los comentarios son recursos distintos y por lo tanto si quisiermos publicar una API REST para que una App pueda construir un blog de este estilo necesitariamos hacer al menos tres llamadas para cualquier entrada.
Esto además de ser incomodo presenta varios problemas, en primer lugar que al tener varias peticiones podriamos tener que hacer algunas de ellas en cascada, puede que para hacer una llamada en concreto primero necesitamos saber el resultado de otra.
En el caso que pongo, para saber la información del autor de la entrada, primero tenemos que esperar a tener el contenido del post donde seguramente devuelva el id del autor.
En el caso de los comentarios pudiera no ser necesario y podriamos hacer la llamada en paralelo a la del post (depende de como hayamos modelado la BBDD), pero hacer llamadas en paralelo también implica una lógica extra para esperar la respuesta del conjunto.
Obtenemos justo la información necesaria
Otro problema es toda la información innecesaria que recibimos y que no necesitamos realmente, por ejemplo si solo queremos mostrar el nombre y los apellidos del autor, pero el recurso de usuario tiene un montón de información extra que no necesitamos, pensemos en tal vez devuelva tambien su fecha de nacimiento, dirección, email, y un sin fin de campos extra que podríamos tener.
Cuando hacemos la llamada toda esa información extra viaja también y hace más pesada la respuesta, consumiendo ancho de banda innecesario (que en el caso de una aplicación movil donde los datos se pagan si puede tener impacto) y haciendo más lenta la respuesta.
Cuantos más datos innecesarios tenga el recurso que pedimos más nos estará penalizando REST.
Por contra en GraphQl podemos hacer una única llamada que devuelva un objeto con los campos que necesitamos exactamente, de manera que es una especificación por naturaleza mucho más eficiente.