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
- 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
@deprecatedal 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.
Curso de GraphQL con Node.js
