Check out a free preview of the full Server-Side GraphQL in Node.js course:
The "Arguments" Lesson is part of the full, Server-Side GraphQL in Node.js course featured in this preview video. Here's what you'd learn in this lesson:

Scott explains that arguments allow clients to pass variables along with queries, and that they can be used in resolvers to get data. Arguments must be defined in the schema, but can be added to any field.

Get Unlimited Access Now

Transcript from the "Arguments" Lesson

>> Scott Moss: Let's get in here. Arguments input types. Let's go, arguments. So arguments allow clients to pass variables along with Queries and mutations when we get there that can be used in your Resolvers to get data. So, let's go back to our codes. We go look at these Resolvers here, the second argument right here.

[00:00:20] Those are gonna be your arguments from the client, that's what that's gonna be.
>> Scott Moss: They must be defined in your schema, so a client can't just pass up an arbitrary whatever they want, and have them appear in that second argument inside the Resolvers. You have to define arguments in your Schema the same way you define everything else.

[00:00:43] You'll notice a trend here. Everything you wanna do in GraphQL has to go through the Schema, so there's no surprises. There is nothing that you're gonna get inside your Resolvers that the Schema didn't already approve. Cuz the Resolver is only being run until the query gets validated. In fact when someone issues a query to your server, the first step is to validate the query.

[00:01:03] Only when that's validated against your Schema do the Resolvers run, unless you do something like persistent queries and they get validated ahead of time, but it has to be validated so you're guaranteed to know what's happening. They can be added to any field though and when I say any field, I really mean any field.

[00:01:20] So you can add arguments to an ID field. You can add arguments to a query field. You can add arguments to an image field, any field you want, you can add an argument to. There's no limit to that. And I know that seems strange why you would want to do that.

[00:01:36] But trust me, there are use cases where you would want to add arguments to fields that exist on a type. Other than just for the obvious ones like queries and stuff like that.
>> Scott Moss: They either have to all be Scalars, or they have to be what's called Input Types.

[00:01:55] And we're gonna go over Input Types in a minute. So Scalars are things like strings, integers, floats, Booleans, IDs. All your arguments have to be that. So, if you wanted to create an argument, let's say for pets, the way you would do it is you would do that, say cool, I wanna add some arguments to my pets here with these parentheses.

[00:02:12] And then you have to name them. So let's say a pet can have- what is it? What is a pet? A pet has a type on it, right? So, obviously a pet has a type, and you can pass a string here. So this is saying, pets now takes a type and its type is string.

[00:02:28] And this follows the same rules as when defining a type, I'm sorry, a field on a type so I can put an exclamation here saying, you have to pass me an argument called type in order to execute this pets query. And you would have to do that and now if you go near resolvers for that pets, you get access to an object whose keys are the names of the arguments that you pass.

[00:02:51] In this case, I would have type here and type will be whatever was passed up. In this case, it's required. So that means this query won't even execute, I'm sorry, this resolver won't even execute, unless there is an argument or yeah, an argument that was passed up. So you don't have to come in here and check to see if type, do this.

[00:03:11] I know it's guaranteed to be there because you put an exclamation there. So it's not a no. You still have to do some other validation probably, like value type validations. But if it's there or not, you would have to check. So that's basically what arguments are and you can do as many as you want.

[00:03:27] Call them whatever. Like I said, they have to be either Scalars or input types. You can't put a type here. My friend says, I can't say,
>> Scott Moss: If a pet has a buddy, I can't say it's a pet. I can't do that. And I'm not saying I can't do that because pet and pet are the same.

[00:03:52] No, I'm saying you can't do that because this is a type, it's not an input type, it's a type. You can only put Scalars in input types. Now we're gonna learn how to make input types. Any questions, yes?
>> Speaker 2: Does an argument order matter in our definition?
>> Scott Moss: Argument order doesn't matter to the server, it only matters to the client when they issue the query, they had to pass arguments in that order, but most of the time, you're gonna name your arguments anyway, which means you're gonna get an object.

[00:04:22] So, it literally doesn't matter, because it's an object. It's not an array, it's an object.
>> Scott Moss: Any other questions?
>> Scott Moss: And I say you can put them on any field. I can do the same thing for image. An example for image, maybe you wanna add transformations to an image.

[00:04:43] So you can say, what height do you want? And that's a string. And what width do you want? And that's a string. Something like that, pretty cool. So, you can add those arguments to anything, and this is where you would want to go write a resolver just for this field to take advantage of these arguments to apply your transformations, yeah.