GraphQL: ¿es el “asesino” de las API REST?

Después de la implementación del soporte GraphQL en Parse, mucha gente se puso en contacto conmigo con algunas preguntas, algunas de ellas preocupadas por el futuro de la API REST.
Va GraphQL a “matarla”?
¿Qué pasará con mis métodos REST API? ¿Tengo que reescribir mi código?

En este artículo voy a cubrir esas preguntas, pero la respuesta corta es: no, usted no tiene que preocuparse porque GraphQL no va a “matar” a la API REST y tampoco tiene que preocuparse por reescribir sus métodos REST API que ya funcionan.

Entonces, ¿cuál es el problema con GraphQL?

Una idea errónea que la mayoría de la gente que me llega tiene, es que GraphQL no está aquí para reemplazar todo el backend.

GraphQL no va a reemplazar el Backend. Ni el Frontend.

GraphQL es un lenguaje de consulta, una forma de especificar para tu API qué información estás buscando, y un tiempo de ejecución que obtendrá esa información de tus datos preexistentes.

Es sólo una manera diferente (mejor manera, diría yo) de decirle a tu App exactamente lo que necesitas saber y luego, recibir esa información.

No tiene que preocuparse por sus métodos REST API ya existentes y en funcionamiento. Seguirán funcionando como hasta ahora aunque adoptes GraphQL. Lo único que hay que tener en cuenta es que GraphQL sólo funciona en Parse 3.5.0 y posteriores, por lo que, si vienes de Parse 2.x o anteriores, eso también implica en el cambio de la estructura del código de Parse.

Así que si estás usando Parse 3.0 o superior, no tienes que preocuparte en absoluto. Sólo tienes que elegir una versión superior a la 3.5.0 y listo.
Si estás usando Parse 2.X, tendrás que hacer algunos cambios en el código.

¿Y por qué GraphQL si mi API REST ya funciona?

Esta pregunta también aparece mucho y realmente creo que hay algunas ventajas clave para elegir GraphQL sobre la API REST.

A corto plazo, si ya tienes tu aplicación escrita usando REST API y está satisfaciendo todas tus necesidades, no tiene sentido migrar a GraphQL y reescribir código sólo por razones.

Por otro lado, si estás empezando ahora o prevés una aplicación en evolución, que ganará complejidad y quieres estar preparado para un mantenimiento futuro simplificado, GraphQL puede realmente sumar y aportarte mucho valor.

¿Ha dicho valor?

Sí, lo he dicho.

GraphQL tiene algunas ventajas clave que simplificarán el desarrollo de código, el mantenimiento a lo largo del tiempo e incluso puede ayudarte a ahorrar en la transferencia de datos. Sí. Has leído bien.

Vayamos punto por punto:

• Simplificar el desarrollo de código

  Al principio, cuando estás empezando con GraphQL, puede que tengas que producir un poco más de código. No dejes que eso te asuste.
  GraphQL hará que sus consultas sean más sencillas de escribir, especialmente si utiliza nuestra Consola GraphQL. Utilizar los esquemas que Parse crea automáticamente y publicar métodos genéricos y específicos tanto para consultas como para mutaciones para todas tus clases te ahorrará mucho tiempo. Y digo mucho.
  ¿Documentación? No hay problema. Eso también lo tenemos cubierto. Y también se genera automáticamente.
  Además, con GraphQL tus desarrolladores podrán contar con esos esquemas que genera Parse, por lo que sabrán de antemano cuáles son los métodos que tienen disponibles, los parámetros para cada método y también cuáles son los retornos (salidas) disponibles. Se acabó adivinar o preguntar a los demás qué hace ese método, qué parámetros requiere o qué devuelve. Todo está ahí para ti.

• Simplificar el Mantenimiento

  El mantenimiento con GraphQL es muy muy fácil. Como las llamadas a la API son esencialmente las mismas, cambiar sólo la consulta o mutación que pasas, añadir o quitar valores devueltos o parámetros es tan fácil como cambiar la consulta o mutación para recibirlos o entregarlos.
  No tienes que cambiar un montón de llamadas, bloques o promesas. Cambia la consulta o mutación: ¡HECHO!

• Ahorra en transferencia de datos

  Después de un tiempo trabajando en Back4app es bastante común ayudar a los clientes a optimizar su código para obtener respuestas más rápidas. Y de todos los problemas que encuentro en los códigos de los clientes, la gran mayoría se debe a la recuperación de datos que la aplicación no necesita en ese momento.
  Un error muy común cuando se trabaja con REST API o incluso con los frameworks Parse es recuperar la información completa de un objeto, y luego utilizar sólo parte de esa información. Por ejemplo:
  Tienes una clase llamada Persona con unas cuantas propiedades: nombre, teléfono, dirección, número de la seguridad social, email, entre otras.
  Normalmente, las personas que utilizan REST API o Parse Frameworks intentan consultar el objeto Persona completo, recuperando todas sus propiedades y, a continuación, utilizando sólo una o dos de ellas.
  Con GraphQL, como debes especificar exactamente la información que necesitas recuperar, el desarrollador no tiene la oportunidad de recuperar información innecesaria, lo que resulta en cargas útiles mucho más pequeñas, y eso se traduce en respuestas más rápidas, menos consumo de planes de datos y menos tráfico saliente en general. ¿No es increíble?

Pruébelo

La mejor manera de ver los beneficios que GraphQL puede aportar a su proceso de desarrollo es probarlo.
Aquí tienes algunos escenarios con los que puedes jugar y ver cómo se comporta:

• Intente crear una consulta GraphQL y no especifique exactamente lo que desea recuperar.

  No podrás hacerlo. Te pedirá obligatoriamente que especifiques lo que quieres y recuperará sólo eso. Nada más.
  Si usted o sus desarrolladores se olvidan de hacerlo, GraphQL no les dejará salirse con la suya.

Falta lo que estoy recuperando

¡Ya está!

• Intento cambiar un objeto usando un Query

  No. ¿Quieres cambiar algo? Usa el método correcto: Mutación.
  Si usted o sus desarrolladores se equivocan de método, GraphQL no les dejará continuar.

¿Un Query para cambiar datos? ¡No no no!

¡Mutation lo tiene cubierto!

• ¿Múltiples Objetos, Múltiples Consultas? ¡No! ¡UNA Consulta!

  GraphQL hace realmente fácil recuperar información sobre múltiples objetos con una sola consulta, simplificando el desarrollo y haciendo el código menos propenso a errores.
  Imagina que tienes una clase Persona y una persona puede tener un perro, de la clase Perro. Necesitas recuperar información de ambas clases: el nombre y la edad de la Persona, y el nombre y la raza del Perro. Muy fácil:

¿Versión? ¿Para qué?

Versionar código es muy de 2018.
Añade nuevos campos a tu consulta. Las llamadas antiguas seguirán funcionando:

Esto funciona

Esto también funciona. Las llamadas al tipo antiguo seguirán funcionando.

¿Campos obsoletos? Fácil también:

Conclusión

GraphQL no está aquí para matar nada. Está aquí para traer una nueva forma de hacer cosas viejas. Mejor, más rápida, más fácil de mantener y menos propensa a errores.

Te mantendrá en el camino cuando te deslices. Te dirá lo que puedes y no puedes hacer.

Junto con Parse y los métodos autogenerados (tanto genéricos como específicos) y la documentación, hará que aprendas a su manera en un abrir y cerrar de ojos.

Si usted nunca le dio una oportunidad, usted debe. Todos los chicos cool están haciendo.

Si quieres saber más sobre GraphQL vs REST echa un vistazo a nuestro post en Medium.