Mutations in GraphQL

This is the third part of my article series on GraphQL. If you want to refresh on the basics and querying you can do so here: Part 1, Part 2

So far we’ve got a working server which can query data. We can now use parameters and do nested queries. If we expand it more we can use it to fetch and aggregate data. Maybe query multiple services and have them all abstracted under our GraphQL server.

Something really important is how to store data. Most of the APIs that we’re using allow us to post data to them, not just fetch data from them. In the GraphQL world this is done with mutations.

What is a mutation?

Technically we can modify data on the server using a query. However, the common accepted convention is that every operation that includes writes should be sent using a mutation, hence the name of the keyword.

Despite that, mutations are really much like the query objects we have been writing so far. They too have a type, arguments and a resolve function.

I’ve taken the liberty of abstracting the two types that we had created (the Post and the Comment) in their separate files so I can use them in the mutations file.

We’ll start by creating a new mutations.js file in the same directory and adding the following require statements at the top.

After that we need to add the basic form of our Mutation object. It isn’t special and everything that you will see here, you have already seen in the query objects that we’ve used so far.

Point your attention first to the fields object. This object will contain all of our mutations (we have just one for now). Our first mutation will be called create and it should have defined it’s return type, it’s arguments and the resolve function.

The type should correspond to the GraphQL type that will be returned, the args are the input that is being passed to the mutation and the resolve function you already know — there we will execute the actual call.

Here is how the file should look in the end. All the arguments defined with their types and the resolve function implemented. This could use some refactoring but for simplicity’s sake we will leave it like that.

What I would suggest is moving the actual fetch call in a service to keep the length of the mutations file to a minimum.

Testing the mutation

Now that we have implemented our mutation we need to test it out in the graphiql dashboard (don’t forget to refresh your server if you haven’t). The setup is a bit different than what we had when we were running simple queries. Now we need to pass some input into the mutation which is done using query variables. You can read more for them in the official docs here.

The top left box is where we call our mutation and defining the variables that we will be using. In the bottom box we define the values of the same variables which must correspond to the type we’ve given them.

Then when we call the actual mutation on line 2 in the top left box we pass them as variables which will automatically map them.

When we specified the return type of the mutations we did it so we can query their result. The returned value can be used like a normal GraphQL query.

I hope this article was helpful to you in your journey to understanding how GraphQL works. You can help me by holding the clap button and sharing this article with friends!