So far we've seen how to build a GraphQL API that serves the user with data stored in the databases. But what about making changes? With a few tweaks in the structure, we can achieve this as well. Let's take a look on things called mutations.
Building an API in GraphQL looks very easy, as you could have already seen based on two previous posts. The thing is that everything looks simple when no parameters are provided, right? Let's take a look at how to make our API just a bit more dynamic.
In the previous post, we've seen how easy it is to set up a simple GraphQL server in Golang. The problem is, that we have hardly done anything special, that would distinguish our API from one written for REST. It's time for something more advanced, that is nested objects and fetching them from different sources.
For a long time building an API (eg. for web applications) has become associated with REST. Meanwhile, less than two years ago, Facebook announced a technology they've been using for some time called GraphQL. It's an alternative way to provide data to the users, where each client can squeeze multiple queries into a single one.