by Indrek Lasn
How to set-up a powerful API with GraphQL, Koa, and MongoDB — CRUD
This is a series where we learn how to set-up a powerful API with GraphQL, Koa, and Mongo. The primary focus will be on GraphQL. Check out part I if you haven’t yet.
So far we can read our data, but there’s a big chance we need to edit our data records/documents. Any complete data platform needs a way to modify server-side data as well.
Okay, imagine this: a company launched a new gadget. How would we go on about adding the record to our database with GraphQL?
Mutations to the rescue!
Think of Mutations like
PUT REST actions. Setting up a mutation is quite straight-forward.
Let’s jump in!
Adding records to our database
Create a file
Inside the file, we will place mutations.
- We import the
GraphQLObjectTypeObjects from the GraphQL library.
- Import the GraphQL type for
- Import the
After importing the stuff we need, we can go on about creating the mutation.
A Mutation is just a plain
GraphQLObjectType like the query we had before. It has two main properties we’re interested in.
The name of the mutation is what appears in the
Fields are where we can place our mutation logic.
Notice I added a new object inside the
fields object. It’s called
addGadget and it would do exactly what it says it will do.
addGadget we have access to three properties,
addGadget type will be
gadgetGraphQLType. The gadget can only have properties which are allowed in the
gadgetGraphQLType type we declared earlier.
addGadget is a query which accepts arguments. The arguments are needed to specify which gadget we want to add to our database.
We declare up-front which arguments the query accepts and the types of the arguments.
Lastly — what happens with the query? Which is precisely why we have the
resolve() function has two arguments:
args. We’re interested in the
args since these are the values we pass to our query.
Inside the resolve we place the logic for creating a new mongo record.
We create a new instance of our
Gadget mongoose model, pass the props we receive from GraphQL as new fields, and finally save the record.
Here’s how the full mutation looks:
Voilà! All we need to do is import the mutation to our
If everything went fine, this is what we should see on our graphiql.
And if we click on it:
Notice how GraphQL creates automatically self-documentation. This is why we have such strong typing.
Firing off the mutation query
A mutation is just a plain graphQL query which takes our arguments, saves it to the Mongo database, and returns the properties we want.
Here’s the catch: every mutation needs to be marked as
Voilà! We successfully created and inserted a new gadget to our mongo database.
If you head over to mlab or whatever provider you’re using, you should see the new record.
Here’s the complete query for our mutation.
Editing our records in the database
What if we want to edit pre-existing records? Surely we can’t rely on never making a typo, or what if the price changes?
Editing a record is also a mutation. Remember, every time we want to change/add a new record, it’s a graphql mutation!
graphql/mutations file and create another mutation. A mutation is just a plain object.
Notice the new mutation called
updateGadget. It’s pretty much a replica of the previous mutation. Notice the extra argument, the
id — that’s because we need to find the existing gadget and change it. We can find the gadget by id.
resolve() function is where it gets more interesting. Ideally, we want to find the gadget by id, change the props, and save it. How would we go on about doing this?
Mongoose gives us a method to do this, called
This returns a promise. If we console.log the promise, we can see a huge blob of properties attached to it. What we can do with the promise is chain it with a
then() method. If promises are a stranger, check out this article I wrote.
Like so: we find the Gadget, change the props, save it. But this returns another promise which we need to resolve.
.catch() for error handling in case we run into errors. Remember, you can monitor your
pm2 logs via the
pm2 logs command. If you run into errors, these will be logged to the pm2 logger.
That’s all! Query time! Look at your Mongo table and pick a random
id from there and edit the corresponding gadget.
And if we inspect the database, we should see the edited record.
Here’s the query for the
Okay, good job for making it this far. So far we have the
Update, but we’re missing the final
Deleting a record from a mongo database is quite straight-forward. All we need is another mutation, since we are, in fact mutating the database.
For deleting records, Mongoose gives us a handy method called
findOneAndDelete – read more about findOneAndDelete here.
Deleting the record just takes one argument, the id. We find the gadget by ID, delete it, and return it. If there’s an error, we’ll log it.
And the query:
Note: Make sure the
id is correct and exists in the database, otherwise it won’t work.
If we head over to our database and inspect it — indeed the record got deleted from our database.
Well done, we have achieved basic
CRUD functionality. Notice how GraphQL is a thin layer between our database and view. It’s not supposed to replace a database, but rather make it easier to work with data, fetching, and manipulating.
Thanks for reading!
Originally published at strilliant.com on January 30, 2019.
hypothetical: You might check every line of code and try to find a typo. No typo found... next, you might start using…www.strilliant.com