Durante el paso de los años vemos cada vez una tendencia en el desacoplamiento entre la parte front-end y back-end de nuestras aplicaciones web. Estamos acostumbrados a día de hoy de contar con un sinfín de frameworks y librerias javascript que nos ayudan mucho en nuestros desarrollos e incluso algunos de ellos deciden emprender su propio camino con sus propias especificaciones en el manejo de datos entre cliente y servidor.
GraphQL, impulsado por Facebook en 2012 y publicado en 2015, es una capa de lenguaje de consultas en el lado servidor que nos permite especificar los datos que queremos obtener de nuestras web API sin necesidad que en esta estén especificados sus endpoints. Este concepto difiere mucho de las arquitecturas orientadas a servicio ya que desde cliente vamos a definir cómo y qué datos vamos a consumir reduciendo notablemente el número de peticiones en comparación con los métodos convencionales al llamar a un servicio REST.
En la imagen anterior mostraba el input y output de nuestra petición mediante GraphQL, vemos que a este le podemos pasar un json con la información que queremos que nos sea retornada. GraphQL es fuertemente tipado y dispone de un modelado previo de nuestros datos mediante un esquema. Sea cual sea el Json con la información que solicitemos devolverá solo y exclusivamente lo que le pedimos y evitando Overfetching de datos como en algunos casos requerimos con los servicios REST.
Bondades de GraphQL
– En la parte cliente se encuentra la definición de lo que se va a recibir:
En GraphQL definiremos nuestro modelo y nuestras consultas. Este es un cambio de papeles de lo que estamos acostumbrados. Esta vez se delega al cliente la definición de las consultas que se deben hacer, librando a la parte backend de tener endpoints y custom endpoints. De esta forma también mantenemos un código más simple en nuestra API y por ende más mantenible.
– Mayor eficiencia en las consultas.
Tal y como muestro en el esquema comparativo con REST, las peticiones se efectúan encapsuladas en una única llamada cada una de ella evitando llamar a un recurso maestro y luego a sus detalles, esta ventaja hace disminuir el número de llamadas por petición y hace de este “Api layer” una capa eficiente en el manejo de datos.
– Es declarativo:
Las consultas realizadas se efectúan “declarando” un conjunto de condiciones, proposiciones, afirmaciones, restricciones, ecuaciones o transformaciones que describen un problema pero no las operaciones necesarias para resolverlo. Esto se resolverá por mecanismos internos.
– Solo envío de los datos necesarios:
GraphQl solo nos devolverá los datos que queramos consumir mediante nuestra “petición json” y nos devolverá su homónimo con estrictamente esos campos populados.
-Aumenta autonomía del desarrollador:
Tener toda la declaración de los servicios de consulta, los datos e incluso las validaciones solo puede traer beneficios en nuestra productividad.
-Fácil mantenimiento de versiones:
Evolución de API sin afectar a las consultas en ejecución.
-Validación antes de ejecutar:
Nuestras querys Json pueden estar dotadas de reglas de validación que se encargarán de controlar de posibles errores en nuestras querys antes de ejecutar
Visión de futuro:
GraphQL viene pisando fuerte. A pesar de estar aún como un Working Draft como especificación en el W3C(World Wide Web Consortium) no se encuentra en una situación ajena a como se encontró REST en su día incluso sus adeptos crecen cada vez más desde que Facebook publicara y liberara GraphQL en 2015 por no decir que ya han comenzado a utilizar esta tecnología GitHub, Pinterest, Intuit, Coursera y Shopify.
GraphQL se va a imponer como una nueva especificación que le hará sombra a REST? O por el contrario se quedará como una especificación más sin levantar demasiada expectación? A nosotros nos ha dejado una buena sensación y exploraremos más a fondo todo su potencial.
Referencias
http://es.slideshare.net/greecejs/graphql-vs-rest
https://andreshevia.com/2016/10/09/graphql/
http://nordicapis.com/5-potential-benefits-integrating-graphql/
https://www.carlosvillu.com/introduccion-practica-a-graphql-i/
Eduard Moret es técnico superior en desarrollo de aplicaciones informáticas y actualmente especializado en tecnología .Net. Amante de la computación gráfica y la programación, Eduard se incorporó a SOGETI en 2015. Actualmente desempeña su labor en la empresa como programador Junior.
Artículos y tendencias sobre soluciones tecnológicas 
Muy interesante. Gracias por el artículo Eduard.
Me gustaMe gusta