36

El rey ha muerto, larga vida a GraphQL

49908Puntos

hace 5 años

Niño mirando hacía abajo diciendo “El futuro es hoy, ¿oíste viejo?

La frase de la imagen aunque tiene un origen de contexto humorístico, la verdad es que aplica bastante para todas las personas que se quedan con los que enseñan en la universidad. La industria tecnológica avanza a pasos cada vez más acelerados y los temarios del colegio quedan un poco obsoletos o atrasados cuando los comparamos con lo que usamos en el día a día.

Un gran ejemplo que me viene a la mente son los Web Services con el tan conocido y viejo protocolo SOAP.

Los servicios web están muertos - larga vida REST

Para quien no recuerde SOAP es un protocolo de acceso a objetos diseñado en 1998, se publicó la versión 1.1 como nota del W3C el 8 de mayo de 2000 y fue mantenida hasta el 10 de julio de 2009.

Cuando fui al colegio a mi me enseñaron a crear un servicio web con el protocolo SOAP y estaba chévere, pero para cuando salí lo primero que noté es que casi nadie usaba esto, el rey era REST y yo no entendía bien esta forma de crear APIs, estaba desactualizado.

Hoy en día se que REST o transferencia de estado representacional (en inglés Representational State Transfer) es un estilo de arquitectura de software que comúnmente utiliza el protocolo HTTP.

Principios REST

  • Protocolo cliente/servidor sin estado: Cada petición HTTP contiene toda la información necesaria para ejecutarla, lo que permite que ni cliente ni servidor necesiten recordar ningún estado previo para satisfacerla.
  • Un conjunto de operaciones bien definidas, POST, GET, PUT y DELETE, que se aplican a todos los recursos de información.
  • Sintaxis universal: Cada recurso cuenta con su propia url.
  • El uso de hipermedios.

Estos principios suenan bastante fáciles de seguir e implementar en tu API, tal es el hecho de que todo proyecto web trae consigo un API REST, pero la verdad es que este estilo de arquitectura trae consigo bastantes complicaciones para el lado del cliente.

Supongamos que nuestro cliente necesita el nombre de un usuario registrado en nuestro API, nuestra API REST probablemente tiene una url para ello similar a /user/user-id y debemos realizar una petición GET, el API nos va a retornar la estructura completa del usuario registrado, probablemente tenga:

  • ID
  • Nombre
  • Email
  • Fecha de nacimiento
  • País de origen
  • Género

Entre muchos otros datos dependiendo del modelo que manejamos en la API. Toda esa información va a recibir el cliente que simplemente solicitaba el nombre del usuario, el cliente simplemente va a tener que desechar todos los datos extra y utilizar únicamente el que le interesa: esto es el Overfetching.

Así como podemos recibir información de más, también existe el caso donde necesitemos realizar más de una petición para obtener toda la información que requerimos: Underfetching.

Tal como lo explicó Facebook por septiembre del 2015, necesitaban un API poderosa y bastante simple para su aplicación móvil, sin los problemas de Overfetching y Underfetching. Así fue cómo desde el 2012 empezaron a desarrollar GraphQL y en el 2015 fue lanzado públicamente.

REST in peace, long live GraphQL.

GraphQL es un lenguaje de manipulación y consulta de datos de código abierto para desarrollar APIs.

Dentro de sus ventajas sobre REST podemos encontrar:

  • Unificación del endpoint para la API, ya no hay necesidad de crear una url para cada recurso.
  • Solamente pides la información que necesitas, no hay necesidad de obtener toda una estructura de datos si unicamente quieres saber el nombre de un usuario.
  • No necesitas crear distintas url según la versión del API, simplemente añades en tu API la línea @deprecated al dato que próximamente vas a dejar de mantener.
  • Se documenta conforme vas desarrollado la API: En GraphQL debes ir creando los modelos de datos que estén a disposición del cliente, dichos datos pasan a formar parte de una mini documentación que crea por sí solo GraphQL para que el cliente pueda verla.

Tal vez el hecho de que Facebook desarrollo está especificación no te de confianza, pero no te preocupes ya que desde el 7 de noviembre del 2018 el proyecto fue movido al cargo de la GraphQL Foundation.

Detrás la GraphQL Foundation encontramos empresas como Facebook, IBM, Shopify AWS, Apollo entre muchas otras. Además, la GraphQL Foundation es alojada por Linux Foundation.

GraphQL es una especificación bastante nueva, pero trae grandes ventajas consigo y para los 4 años que lleva ha recibido un gran amor por parte de la comunidad. Es muy seguro que la GraphQL Foundation va hacer madurar y convertir esta especificación en el estándar de la web. GraphQL es el futuro y desde hoy puedes aprender las bases con el nuevo Curso Básico de GraphQL.

No dejes que la tecnología te rebase, mantente actualizado y #NuncaParesDeAprender.

Demian
Demian
demian

49908Puntos

hace 5 años

Todas sus entradas
Escribe tu comentario
+ 2
Ordenar por:
4
20637Puntos

Definitivamente graphql llegó para quedarse debido a la sencillez y versatilidad que aporta tanto a clientes como servidores 🤓

3
36044Puntos

Puntos extra por las referencias a Malcom. 👌

1
6099Puntos

Recomiendas empezar por el de GraphQL que hay ahora disponible o esperar. Los contenidos son diferentes?

1
49908Puntos
5 años

Hola Ivan, el contenido del Curso Básico de GraphQL que sale el próximo martes esta totalmente centrado en crear un CRUD con GraphQL, puedes ver el temario completo en acá.

Yo te recomiendo esperar y en cuanto salga tomar el nuevo curso.

1
5 años

Segun veo el temario es basicamente lo mismo… molaria que sacaran un curso de graphql con reactjs… ya que solo se esta enseñando la parte de usar graphql en servidor… y no en cliente.

3
49908Puntos
5 años

Hola Jordi, un curso centrado en GraphQL del lado del cliente con React estaría genial, pero ¿Qué te parece próximamente un super curso de React Avanzado donde no solamente veas Apollo, sino también React Hooks, SEO con React, PWA y mucho más?