Use Arguments in a GraphQL Mutation

Instructor: [00:00] This GraphQL server has one type of post and we have one query where we can get a list of post. We have an array with some post data, just a single object right now. We have a resolver where we can get those post out. Run the query and we'll get that data here.

[00:16] If we want to create new post from the client, we can use GraphQL mutations. Right next to the root query type, provide a root mutation type. Within that root mutation type, we need a mutation to say that we're going to write some data. This can be named anything, but typically, something like create post works well.

[00:35] After we create the post, we need to send something back to the client. In this case, we'll just send back that post we created. This is a common pattern in most applications. When you write some data, you want to get that data back so that you can display it in the application or do what you need to do.

[00:51] The mutation is now in the schema and we now need it in our resolvers as well. Right next to the root query resolver, put a root mutation resolver. Match up that createPost mutation that we created above.

[01:05] Let's just hardcode in a new post for now, so const new post equals this object. For the ID, maybe we can do just posts.length + 1, that's a quick and dirty way to increment.

[01:16] The title can just be Foo, description can just be Bar, and body can be Baz. Beneath this, we can do a posts.push, the newPost. Finally, we will return the newPost. When we run that mutation from the client, we need to key it with mutation like this.

[01:36] Then, we can call createPost. We'll say that we want to receive back the ID, title, description, and body. Run that. There's our new post.

[01:49] It's probably not very common that you'll want to hardcode data in like this. Instead, you want to receive it from the client. For that, we can tell our mutation that we want it to receive arguments. In the createPost mutation in the schema here, let's tell it that we want to receive three arguments.

[02:05] Title will be a string that will be required. Description will be a string as well, but not required because it's not required in our post type. Body, that's a string, also required.

[02:18] What we've done here is we have told our GraphQL schema that it should expect these arguments. To make use of them, that happens down here in the resolver.

[02:26] GraphQL resolvers have four arguments. The first is parents, the second one is args, that's the one we'll need. Let's use that down here. Instead of having our hardcoded data, let's get rid of that, this args argument is going to be an object with the keys that we provide, mapping up to title, description and body. We can just spread that out here in this object. Come back over here to create post.

[02:53] In here now, let's provide those arguments, so title will be foo, description bar, body bass. Run that and we get our post back. If we run it again, we'll get three and four, et cetera.

[03:11] This works fine to provide our arguments one by one. If we start to get into this situation where we have lots of arguments to provide, then it gets a bit annoying to provide them one by one.

[03:22] As the best practice, let's give ourselves an input type. Come up here and put in input and we'll this post input. Post input is just going to have these details that we've already used, so we can even just cut that out and put them into post input here.

[03:42] In create post, it just is a matter of saying that instead of those individual arguments, we want a single argument called input, which maps up to post input. We'll say it's required.

[03:53] The only change down here in the resolvers is instead of args itself, we have to say args.input because the data coming in is going to be on the input key.

[04:04] The change we make over here is instead of having each of these individually go in, we put it on an input object. There's our input with title, description and body.