Desde el comienzo de la web, crear APIs ha sido una tarea difícil para los desarrolladores. El modo en que creamos APIs debe evolucionar de modo que seamos capaces de desarrollar APIs intuitivas y bien diseñadas.
En los últimos años, GraphQL ha crecido en popularidad entre los desarrolladores. Muchas compañías han empezado a adoptar esta tecnología para construir sus APIs. GraphQL es un lenguaje de consulta desarrollado por Facebook en 2012 y lanzado públicamente en 2015 y su popularidad ha ido aumentando. Está siendo utilizada por grandes compañías como Spotify, GitHub, NYTimes, Netflix, Walmart y la propia Facebook, entre otros.
En esta serie de tutoriales, vamos a examinar GraphQL, entender que es y ver qué características hacen que este lenguaje de consulta sea tan intuitivo y fácil de usar.
Así pues, empecemos por examinar los problemas de REST y como GraphQL los resuelve. También averiguaremos por qué las empresas están usando GraphQL y por qué es el futuro de las APIs
Oh, REST
Hace mucho tiempo, cuando cambiamos el diseño de nuestras APIs de SOAP a REST, pensamos que este movimiento le daría a los desarrolladores más flexibilidad en su trabajo. No podemos negar que funcionó bastante bien durante algún tiempo y fue un buen cambio en su momento. A medida que las aplicaciones y la web han ido haciéndose más complejas, las APIs evolucionaron con ellas, siguiendo estos cambios.
Sin embargo, REST tiene bastantes problemas, veamos cuales son:
Diversos endpoints
Cada recurso de REST viene representado por un endpoint (punto de entrada). Así que en una aplicación real, acabaríamos teniendo un montón de endpoints para un montón de recursos. Si quieres hacer una petición GET, necesitarás un endpoint específico para dicha petición, con sus propios parámetros. Si quieres hacer una petición POST, necesitarás otro endpoint sólo para esa petición.
Pero, ¿qué problema tiene esto? Imaginemos que estamos construyendo una enorme red social tipo Facebook. Acabaremos teniendo multitud de endpoints lo que significa que los programadores deberán dedicar mucho tiempo al desarrollo y mantenimiento de esas APIS.
Affiliate Ad – Libro recomendado:
Learning GraphQL: Declarative Data Fetching for Modern Web Apps
Excesiva o insuficiente información
Un problema que molesta a los desarrolladores que las APIs REST a veces recuperar o demasiada o insuficiente información. Esto es porque las APIs REST siempre devuelven una estructura fija. No podemos obtener exactamente la información que necesitamos a menos que creemos un endpoint específico para ello.
Así, si necesitamos un único dato, tenemos que trabajar con el objeto entero que lo contiene. Por ejemplo, si sólo necesitamos el nombre, apellido y edad de un usuario de la API REST, no hay modo de obtener estos datos sin recuperar el objeto completo.
También existe el problema de recuperar información insuficiente. Si queremos obtener datos de dos recursos diferentes, tenemos que hacer dos llamadas diferentes a dos endpoints diferentes. En una aplicación grande, eso no escala bien ya que habrá casos en los que sólo necesitemos un trozo concreto de los datos, no el objeto entero. Ahora, imagina que construimos una aplicación que va a tener 100 endpoints. Imagina la cantidad de trabajo y el código que tenemos que escribir. Esto se hará cada vez más complicado. El código se vuelve complicado de mantener y los desarrolladores se sentirán perdidos.
Versionado
Unos de los puntos ‘dolorosos’ de las API REST es el versionado. Con API REST, es muy habitual ver APIs con v1 y v2. En GraphQL esto no es necesario, ya que puedes evolucionar tu API añadiendo nuevos tipos o eliminando antiguos.
En GraphQL todo lo que necesitas para evolucionar tu API es escribir código nuevo. Puedes definir nuevos tipos, consultas y mutaciones sin necesidad de lanzar otra versión de tu API.
Así pues, en GraphQL no verás endpoints como estos:
https://example.com/api/v1/users/12312
https://example.com/api/v2/users/12312Por qué GraphQL es el futuro
En 2012, Facebook se encontró con varios problemas a medida que desarrollaban sus aplicaciones móviles, lo que les llevó a crear GraphQL. Estos problemas son muy comunes, especialmente cuando hablamos de diseño RESTful. Como hemos visto, los problemas eran:
- Bajo rendimiento
- Multitud de endpoints
- Demasiado o insuficiente información recuperada
- Lanzar una nueva versión para cada cambio
- APIs difíciles de comprender
Con varios conceptos en mente, Facebook desarrolló una manera mejor de diseñar APIs y la llamaron GraphQL. Básicamente es el sustituto de REST, con varias mejoras.
Con GraphQL tenemos tenemos nuevas características que nos dan ‘superpoderes’ para construir nuestra API. Veámoslas una a una:
Endpoint único
No necesitamos construir varios endpoints. Con GraphQL, tan sólo tenemos un endpoint, y con ello podemos obtener toda la información que queramos con una única petición. Básicamente, GraphQL envuelve tus consultas, mutaciones y suscripciones en un endpoint y les hace disponibles. Mejora el ciclo de desarrollo porque no necesitas hacer dos peticiones para recuperar datos de dos recursos diferentes. Además, imagina que estamos construyendo una aplicación grande, no tendremos multitud de endpoints ni toneladas de código como en REST. Tendremos un único endpoint y con él podemos realizar tantas consultas como queramos.
Además, como hemos dicho anteriormente, el enfoque endpoint único’ hace que tu API sea autodocumentada ya que no hay necesidad de crear documentación porque los desarrolladores ya saben como usarla. Puede entender la API sencillamente mirando el código. Hablaremos más de ello próximamente (en el próximo tutorial de esta serie). Parece magia, ¡pero es GraphQL!
Con GraphQL sólo recuperas los datos que necesitas
Nunca más te faltarán o sobrarán datos. Obtienes sólo los datos que necesitas. ¿Recuerdas los problemas de bajo rendimiento de los que hablamos antes? Estos desaparecen en GraphQL ya que mejoran el rendimiento de tu API, especialmente con conexiones lentas.
GraphQL facilita empezar a construir APIs y ser consistente
Mucha gente piensa que GraphQL es complicado porque implica un esquema y un único endpoint. Una vez que empiezas a desarrollar APIs con él, descubres que es más fácil de lo que pensabas. Una API de un solo endpoint es de gran ayuda cuando estás creando una web o aplicación. Hace tu API más autodocumentada y no es necesario escribir mucha documentación acerca de ella.
Si no usas JavaScript como lenguaje principal, no es problema. GraphQL es un lenguaje de consultas agnóstico, lo que significa que puedes usarlo con cualquier lenguaje. En el momento de escribir este tutorial, GraphQL soporta 12 lenguajes.
GraphQL es el futuro
El hecho de que GraphQL sea un lenguaje de consulta de código abierto significa que la comunidad puede contribuir y realizar mejoras. Cuando Facebook lo abrió a la comunidad, ganó mucha popularidad entre los desarrolladores. Ahora, GraphQL ha estado creciendo muy rápidamente a medida que los desarrolladores construyen APIs con él. Sin embargo, hay gente que sigue preguntándose si va a reemplazar a REST o a convertirse en un nuevo modo de construir aplicaciones.
Al principio, pensé que GraphQL eran sólo expectativas y tan sólo un modo diferente de crear APIs. Sin embargo, cuando he empezado a estudiarlo, descubrí que GraphQL tiene características esenciales necesarias para crear APIs modernas para aplicaciones modernas, porque realmente encaja bien con las nuevos ‘stacks’ (pila tecnológica).
Así que si puedo decirte algo ahora es: sí, GraphQL es el futuro de las APIs. Por eso las grandes empresas apuestan por él.
En noviembre de 2018, GraphQL creó la Fundación GraphQL, en colaboración con la Fundación Linux. Este lenguaje de consulta anima a los desarrolladores a construir más documentación, herramientas y soporte para el lenguaje. Esta fundación garantizará un futuro estable, neutral y sostenible para GraphQL. Así que este es otro motivo para considerar a GraphQL el futuro de las APIs.
Naturalmente, so sustituirá a REST inmediatamente porque muchas aplicaciones lo usan y es imposible rehacerlas de la noche a la mañana. A medida que más y más empresas adopten GraphQL, tanto UX (experiencia de usuario) y DX (experiencia digital) irán mejorando.
Conclusión
GraphQL es realmente el futuro de las APIs y necesitaremos aprenderlo. Por eso he decido crear una serie de 4 tutoriales que nos enseñarán como trabajar con lo mejor de GraphQL, empezando por Queries (consultas) y Mutations (mutaciones).
Así que permanece atento y nos vemos en el próximo tutorial
Puede ver el artículo original en inglés en https://medium.com/free-code-camp/why-graphql-is-the-future-of-apis-6a900fb0bc81