Anatomy of a Mutation (Apollo GraphQL)

What is a Mutation?

Mutations are like queries, but they are called mutations. Thats it. Funny, you can probably write a query with a side-effect in the resolver. But, since there IS a difference between these concepts in GraphQL, we should keep Mutations separate from Queries.

What does a Mutation look like?

In Apollo it’s quite simple:

Mutation Resolvers

Let’s take a look at the resolver for submitRepository.

What are the parameters?

So we have some positional arguments here, but what you need to know in order to be successful with resolvers is that the param structure reads like this:

What about Optimistic UI?

The great thing about Apollo Client is it’s forward thinking design. From experience, we needed a way to optimistically update data already fetched in the store with the results of our Mutations. Thanks to Slava Kim and David Woody Apollo Client now gives users the tools to keep updates to the store as efficient as possible while keeping re-renders at a minimum.

The Anatomy of Optimistic UI

Credits Slava Kim/ApolloStack
  1. EVERYTHING BEGINS AND END WITH THE USER. They are the power driving mutations through their interface, and they are the ones expecting the side effects of those mutations reflective in the views they are interacting with.
  2. The flow is as Unidirectional as possible. Much like the paradigms of Flux, this flow moves in one way starting from the User to the Server then back to the user.
  3. An Optimistic Response is an illusion. Programmers are magicians, and thus we THINK we know that you know what you just mutated. So what we do in optimistic scenarios is give you what you thought was going to happen. A perfect example is adding a post to a list of posts. You are the author of the post in question, so our optimistic response is taking this post and adding it to the list right away. Why? So this looks like our website is super fast, and the user gets INSTANT feedback on actions they take in the system.
  4. The Server is the source of truth. You can see once the Optimistic Response is sent to the User’s view, the server takes the same request and goes through its processing. Once its ready to reaffirm the client that what it has is correct, it jumps over the latency divide and updates the store. Most of the time, the user will not notice a change. But there will be instances that the server may have a more complete view of the world and will update the optimistic response with the truth. Bottom line, design systems that provide the least amount of judder to the user. Keep optimistic responses similar to the latency bound response.
  5. All of this is possible because Redux is awesome. Shameless plug.

Conclusion

This was pretty much a some random ramblings about GraphQL Mutations. As you can see, and I’ve been trying to stress in all my posts, Mutations/Queries are just pointers to some function. They’re super harmless and easily approachable! So let’s get this going and start using Apollo today!

--

--

Software Engineer at Workpop, Inc.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Abhi Aiyer

Abhi Aiyer

Software Engineer at Workpop, Inc.