Consultas y mutaciones de GraphQL en distintas versiones de Parse

A medida que Parse evoluciona con el tiempo, algunos aspectos cambian para mejorar el rendimiento, la compatibilidad y facilitar el desarrollo.
Uno de estos aspectos es el soporte de GraphQL que evolucionó desde Parse 3.5.0 con el tiempo hasta la última versión disponible, 3.9.

Aquí en Back4app, tenemos tres versiones principales que implementan cambios en las consultas y mutaciones GraphQL, específicamente: 3.7.2, 3.8 y 3.9 y hoy te guiaré a través de las diferencias entre esas versiones, mostrando lo que cambió y lo que no.

Introducción

La evolución es obligatoria cuando se despliegan soluciones a largo plazo para los clientes y Parse no es una excepción.

A medida que los estándares GraphQL comenzaron a hacerse más populares y utilizados, la comunidad demandó una mejor integración, simplificación de uso e intuitividad. Y como mantenedores de Parse y contribuyentes activos, Back4app escuchó esas voces y puso mucho esfuerzo para lograr esos resultados en la plataforma Parse de código abierto.

Nuestros desarrolladores aportaron nuevas funcionalidades a lo largo del tiempo, como la integración con Cloud Code, pero la comunidad seguía pidiendo una sintaxis GraphQL más consistente sobre marcos y plataformas, y con Parse 3.9 lo conseguimos y lo entregamos a la comunidad para que se beneficiara de ello.

Mientras esa sintaxis evolucionaba, se hicieron algunos cambios clave, así que dependiendo de la versión de Parse que uses, debes elegir la sintaxis correcta para ella: 3.7.2, 3.8 y 3.9 tienen sintaxis ligeramente diferentes para conseguir los mismos resultados.
Por esta razón, estoy escribiendo este artículo, para que lo tengas todo documentado en un solo lugar y, mientras lo hago, recomiendo encarecidamente a los usuarios que puedan actualizar su Parse a la 3.9 junto con la nueva sintaxis, nuestra versión más compatible con la sintaxis entre plataformas y frameworks hasta el momento.

A continuación te muestro algunos ejemplos.

Salud de la API

La consulta de salud de la API no ha cambiado entre las versiones, y puedes llamarla de forma consistente consultando

lo que dará como resultado la misma respuesta en todas las versiones:

Creación de un objeto

La mutación para crear un objeto ha cambiado con el tiempo para ser más consistente entre los distintos frameworks GraphQL e incluye cambios de última hora que deberías tener en cuenta antes de cambiar la versión Pare.

Uso de una Mutación Genérica

En Parse 3.7.2 podías simplemente pedir la creación de un objeto y una clase se crearía automáticamente para ti:

En Parse 3.8, hay un ligero cambio ya que la consulta de objetos fue eliminada, pero aún puedes pedir la creación de un objeto y la clase será creada automáticamente:

En Parse 3.9, sin embargo, primero debes crear tu clase, añadiendo explícitamente sus campos:

y sólo entonces podrás guardar un objeto usando su método específico (más abajo).

Usando un método específico (Mutación de Clase)

Los métodos específicos (métodos de clase, en este caso, una mutación de clase) también han cambiado:

En Parse 3.7.2 era:

En Parse 3.8 se eliminó la propiedad objects:

Y finalmente en Parse 3.9, la propiedad ObjectId fue renombrada por id, para que pudiera ajustarse a los estándares:

Obtener un objeto

La obtención de objetos también ha evolucionado con el tiempo para mejorar la coherencia y la compatibilidad.

Utilizar una consulta genérica

Puedes especificar el nombre de la clase y el ID del objeto para recuperar un objeto específico, usando el método genérico GET, que funcionaría para cualquier clase.

Parse 3.7.2:

Más tarde, Parse 3.8 eliminó los objetos permitiendo una llamada más simple:

Parse 3.8:

Con la llegada de Parse 3.9, el método genérico GET fue eliminado y debes usar el método específico de clase para recuperar objetos (más sobre esto abajo).

Utilizando un método específico (Class Query)

Los métodos específicos también cambiaron según la versión de Parse.

En Parse 3.7.2 teníamos:

Más tarde, en Parse 3.8 también eliminamos la propiedad objects para facilitar la llamada:

Y en Parse 3.9 el objectId fue reemplazado por id para una mejor consistencia entre frameworks:

Encontrar un objeto

La búsqueda de objetos también ha evolucionado con el tiempo para mejorar la coherencia y la compatibilidad.

Uso de una consulta genérica

Puedes especificar el nombre de la clase para recuperar una lista de objetos, usando el método genérico FIND, que funcionaría para cualquier clase.

Parse 3.7.2:

Más tarde, Parse 3.8 eliminó los objetos permitiendo una llamada más simple:

Parse 3.8:

Con la llegada de Parse 3.9, el método genérico FIND fue eliminado y debes usar el método específico de clase para recuperar objetos (más sobre esto abajo).

Uso de un método específico (Consulta de clase)

Los métodos específicos también cambiaron según la versión de Parse.

En Parse 3.7.2 teníamos:

Más tarde, en Parse 3.8 también eliminamos la propiedad objects para facilitar la llamada:

Y en Parse 3.9 el objectId fue reemplazado por id para una mejor consistencia entre frameworks:

Actualizar un objeto

La actualización de objetos también tuvo que cambiar para mejorar la coherencia y la compatibilidad.

Uso de una consulta genérica

Podías especificar el nombre de la clase y el ObjectID para actualizar un objeto, usando el método genérico UPDATE, que funcionaría para cualquier clase.

Parse 3.7.2:

Más tarde, Parse 3.8 eliminó los objetos permitiendo una llamada más simple:

Parse 3.8:

Con la llegada de Parse 3.9, el método genérico UPDATE fue eliminado y debes usar el método específico de la clase para recuperar objetos (más sobre esto abajo).

Uso de un método específico (Consulta de clase)

Los métodos específicos también cambiaron según la versión de Parse.

En Parse 3.7.2 teníamos:

Más tarde, en Parse 3.8 también eliminamos la propiedad objects para facilitar la llamada:

Y en Parse 3.9 la llamada se mantuvo similar a la 3.8, pero el objectId fue renombrado a id en la llamada:

Métodos de aplicación

Los métodos de aplicación tuvieron que seguir los cambios y ajustarse a los nuevos estándares. Las consultas y mutaciones específicas de la aplicación también han cambiado.

Registro de un usuario

El registro de nuevos usuarios ha seguido el protocolo a lo largo del tiempo y se ha ajustado en consecuencia:

Parse 3.7.2:

Más tarde, Parse 3.8 mantuvo la llamada:

Parse 3.8:

Con la llegada de Parse 3.9, la propiedad objectId cambió a id para ajustarse:

Inicio de sesión de un usuario

El inicio de sesión de un usuario cambió de la misma manera:

Parse 3.7.2:

Más tarde, Parse 3.8 mantuvo la llamada:

Parse 3.8:

Con la llegada de Parse 3.9, la propiedad objectId cambió a id para ajustarse:

Obtención de un usuario registrado

La recuperación de información sobre un usuario registrado también ha tenido que cambiar. Todavía tienes que pasar la cabecera “X-Parse-Session-Token” junto con un identificador de sesión válido para ese usuario, pero la consulta en sí ha cambiado:

Parse 3.7.2:

Más tarde, Parse 3.8 cambió la consulta ME al nuevo formato VIEWER:

Parse 3.8:

Con la llegada de Parse 3.9, la propiedad objectId cambió a id para ajustarse. Si no la necesitas, la sintaxis es la misma que en 3.8:

Conclusión

Con la evolución de Parse junto con otras plataformas y formatos a lo largo del tiempo, era natural que Parse siguiera cambiando para simplificar el desarrollo y mantener la coherencia y la interoperabilidad.

A medida que aparecían nuevos estándares, Parse tenía que aplicar cambios para no diferir de los principales componentes con los que se integra.

Como ávido usuario de Parse, yo mismo esperaría algunos cambios más con el tiempo. Buenos cambios. Cambios que tengan sentido y que permitan a todos alcanzar sus objetivos.

En Back4app estamos orgullosos de haber ayudado a esta evolución y aconsejamos a todos los que usan GraphQL que actualicen Parse a 3.9 junto con sus consultas y mutaciones GraphQL. Se beneficiarán de un lenguaje de consulta mucho más consistente.

La versión 4.0 está en el horno. ¿Qué traerá?