GraphQL Queries and Mutations on distinct Parse Versions

As Parse evolves over time, some aspects of it change for better performance, better compatibility and easier development.
One of these aspects is the GraphQL support that evolved from Parse 3.5.0 over time to the latest version available, 3.9.

Here at Back4app, we have three main versions that implement changes in the GraphQL queries and mutations, specifically: 3.7.2, 3.8 and 3.9 and today I will walk you through the differences among those versions, showing what did change and what did not.

Introduction

Evolution is mandatory when deploying long term solutions to customers and Parse is no exception.

As GraphQL standards started to get more popular and used, the community demanded better integration, simplified usage, and intuitiveness. And as Parse maintainers and active contributors, Back4app heard those voices and put a lot of effort to achieve such results in the open-source Parse platform.

Our developers brought new functionalities over time, such as the Cloud Code integration but the community kept asking for a more consistent GraphQL syntax over frameworks and platforms, and with Parse 3.9 we achieved it and delivered it to the community to benefit from.

While that syntax evolved, a few key changes were made, so depending on the version of Parse that you use, you must pick the correct syntax for it: 3.7.2, 3.8 and 3.9 have slightly different syntaxes to achieve the same results.
For this reason, I am writing this article, so you have it all documented in one place and, while I do that, I strongly recommend users that can update their Parse to 3.9 along with the new syntax, our most cross-platform/cross-framework syntax compatible version yet.

Below I’ll show you some examples.

API Health

The API health query did not change among the versions, and you can consistently call it by querying:

which will result in the same response among versions:

Creating an Object

The Mutation for creating an object did change over time to be more consistent among distinct GraphQL frameworks and include breaking changes that you should consider before changing the Pare version.

Using a Generic Mutation

In Parse 3.7.2 you could simply ask for the creation of an object and a class would be automatically created for you:

In Parse 3.8, there is a slight change as the objects query was removed, but you can still ask for the creation of an object and the class will be automatically created:

In Parse 3.9, however, you must first create your class, explicitly adding its fields:

and only then you can save an object using its specific method (below).

Using a specific method (Class Mutation)

Specific methods (Class methods, in this case, a Class mutation) also changed:

In Parse 3.7.2 it was:

In Parse 3.8 the objects property was removed:

And finally in Parse 3.9, the ObjectId was renamed for id, so it could conform to the standards:

Getting an Object

Retrieving objects also has evolved over time for better consistency and compatibility.

Using a Generic Query

You could specify the Class name and Object ID in order o retrieve a specific object, using the generic GET method, that would work for any class.

Parse 3.7.2:

Later on, Parse 3.8 removed the objects allowing for a simpler call:

Parse 3.8:

With the arrival of Parse 3.9, the generic method GET was removed and you should use the specific class method in order to retrieve objects (more about it below).

Using a specific method (Class Query)

The specific methods also changed according to the Parse version.

In Parse 3.7.2 we had:

Later on, in Parse 3.8 we also removed the objects property for easier calling:

And in Parse 3.9 the objectId was replaced by id for better consistency among frameworks:

Finding an Object

Finding objects also has evolved over time for better consistency and compatibility.

Using a Generic Query

You could specify the Class name in order o retrieve a list of objects, using the generic FIND method, that would work for any class.

Parse 3.7.2:

Later on, Parse 3.8 removed the objects allowing for a simpler call:

Parse 3.8:

With the arrival of Parse 3.9, the generic method FIND was removed and you should use the specific class method in order to retrieve objects (more about it below).

Using a specific method (Class Query)

The specific methods also changed according to the Parse version.

In Parse 3.7.2 we had:

Later on, in Parse 3.8 we also removed the objects property for easier calling:

And in Parse 3.9 the objectId was replaced by id for better consistency among frameworks:

Updating an Object

Updating objects also had to change for better consistency and compatibility.

Using a Generic Query

You could specify the Class name and ObjectID in order o update an object, using the generic UPDATE method, that would work for any class.

Parse 3.7.2:

Later on, Parse 3.8 removed the objects allowing for a simpler call:

Parse 3.8:

With the arrival of Parse 3.9, the generic method UPDATE was removed and you should use the specific class method in order to retrieve objects (more about it below).

Using a specific method (Class Query)

The specific methods also changed according to the Parse version.

In Parse 3.7.2 we had:

Later on, in Parse 3.8 we also removed the objects property for easier calling:

And in Parse 3.9 the call was kept similar to 3.8, but the objectId was renamed to id in the call:

Application Methods

Application methods had to follow the changes and conform to the new standards. Queries and Mutations specific to the App have changed too.

Signing Up a User

Signing up new users followed the protocol over time and adjusted accordingly:

Parse 3.7.2:

Later on, Parse 3.8 kept the call:

Parse 3.8:

With the arrival of Parse 3.9, the objectId property changed to id to conform:

Logging in a User

Logging in a user changed in the same way:

Parse 3.7.2:

Later on, Parse 3.8 kept the call:

Parse 3.8:

With the arrival of Parse 3.9, the objectId property changed to id to conform:

Getting a Logged User

Retrieving information about a logged user had also to change. You still have to pass the “X-Parse-Session-Token” header along with a valid Session Token for that user, but the query itself has changed:

Parse 3.7.2:

Later on, Parse 3.8 changed the ME query to the new VIEWER format:

Parse 3.8:

With the arrival of Parse 3.9, the objectId property changed to id to conform. If you don’t need it, the syntax is the same as 3.8:

Conclusion

With the evolution of Parse along with other platforms and formats over time, it was only natural that Parse kept changing in order to simplify development and keep consistency and interoperability.

As new standards showed up, Parse had to apply changes so it wouldn’t differ from the main components it is integrating to.

As an avid Parse user, I myself would expect a few more changes over time. Good changes. Changes that make sense and allows everyone to achieve their goals.

We in Back4app are proud to have helped this evolution and we advise everyone using GraphQL to update Parse to 3.9 along with your GraphQL queries and mutations. You will benefit from a much more consistent querying language.

Version 4.0 is in the oven. What will it bring?