Arguments & Input Types Solution

[00:00:00]
>> Scott Moss: So you were tasked with adding some inputs to the pets query, than adding a pet query here. So let's just finish that. So right now, I already have a pet input that I created through the last example. So I'm just going to expand on that, and actually finished a resolver to do that, and already did most of that too.

[00:00:18]
So I'm just gonna return In front of this, and the way find many works, and the way find one works, it just takes an object of fields and values. So, if you look at my pet input, it's an object of fields and values, so I can just pass the entire input objects in like that, and it just works.

[00:00:35]
It'll filter for me, so I'll do that. That'll do my pets. And then, for the one pet, I need to make another input here. And then depending on what you decided to filter on, you might have just reused the pet input, which allows you to select one pet based off this criteria.

[00:00:53]
So you can just do that, and I'll make a resolver for that, which is called pets. And it also has an input, and take the context here and I'm just gonna do literally the same thing as I have up here, but, instead of find many it should be find one so we'll do that.

[00:01:12]
Make sure everything is saved. What is this? Why is this not saved? Okay, and we don't have anything in our database, so I'm gonna ask some stuff here so we can actually see this working. So, I know a pet looks like, if I go to scheme.json, I know what pet looks like this as an ID, a type, and stuff like that.

[00:01:34]
So, I'll just make some right quick hard code's on in here.
>> Scott Moss: And give it some ids of 1. Give this one an id of 2.
>> Speaker 2: Your createdAt needs to be a number.
>> Scott Moss: Thank you, createdAt some number. Wait, No, createdAt, I think it's a string on mine, let's see, we'll see, we'll figure it out.

[00:02:04]
Name, moves, type, dog, let's do dog like that, and we'll do the same thing, like that. Some more Time stuff in there. I actually have a cat named Daryl, so I'm gonna put Daryl. [LAUGH]
>> Speaker 3: Great cat name.
>> Scott Moss: It's a good cat name, he has a wardrobe of pajamas.

[00:02:32]
>> Speaker 3: [LAUGH]
>> Scott Moss: [LAUGH] And we just shaved him so he looks like a lion now, it's hilarious. Cool, so we got that. Restart this server here. Everything looks good.
>> Scott Moss: Look at our docs. So, if you look here, you can see in our docs in GraphQL Playground, you can see that it actually takes note of the inputs that we have.

[00:02:59]
Pet input and things like that. We can even select the pet input, and see what that looks like. And then obviously, we can keep drilling down and doing all that stuff like that. So we get the full example, if we look at the schema. We can also see our inputs showing up on the schema, with our inputs being placed inside of our queries and all sorts of things.

[00:03:17]
So, pretty good. So now, what we'll do, is get this to go away, go away. Thank you, did not want to go away. And we'll do some pets like this, will pass up some arguments, so inputs. And I'm gonna say, I wanna type dog, and I'll get to type here and name, and we run this.

[00:03:47]
And you can see, I only get back an array of pets whose type is dog, if I change this to cat, I should get back. I guess I spelled cat definitely on the server than I did. Yeah, put a S, gotta love that Jason. Boom, now we get a cat.

[00:04:09]
Right, so that's for pets, for pet, I just open up a new tab here, gonna put pet. And pretty much gonna do the same thing. I was gonna get one pet.
>> Scott Moss: That has a type of,
>> Scott Moss: Cat and give it a name and I get Daryl. Yes?

[00:04:32]
>> Speaker 4: Is case sensitivity going to depend on the files system.
>> Scott Moss: Cases activity for what exactly?
>> Speaker 4: For the query. So for example, if you type in cat, that's all lower case on a case insensitive file system, would it care?
>> Scott Moss: So this has nothing to do with file systems in this case.

[00:05:00]
This is explicitly only looking at this value here.
>> Speaker 4: Gotcha.
>> Scott Moss: Right? But node, or I guess it's not node. I guess it's just MacBooks in general. MacBooks are insensitive to case sensitivity.
>> Speaker 4: The default is case sensitive.
>> Scott Moss: The default case sensitive. Okay, I want to change mine.

[00:05:21]
But yeah, but graph field is not looking at the files as anything like that, this type is literally, I mean, I guess I could just show you inside of, let me show you. If I go to the pet. Stuff inside of five minute you can see that it's getting a pet from the Jason file, and it's applying the filter that you passed and this is getting value.

[00:05:43]
So it's only looking at those fields and those values, and it's doing a direct comparison. It's literally using lodash or whatever lodash does to compete those values. That's what it's doing. Yeah. Any questions on input types and arguments? Yes?
>> Speaker 5: Yeah, one quick question. If you used the same input type, the pet input, for both of the queries, but then, like so, for find many, that makes sense you can expose multiple values, but then with find one, it doesn't really make sense to

[00:06:16]
>> Scott Moss: Exactly
>> Speaker 5: Create by name it, but then if you want to so use pet input, Is there a way to specify that you can only allow queries by the id? On that same pet input or do you have to create another pet input-
>> Scott Moss: So, that's like a code level thing.

[00:06:29]
So, whenever you have to check the value of something. You have to do that on resolver. Because GraphQL is just static, it's not gonna check the value when you statically type your scheme. So, if you want that grade of graduality, then you have to do that inside your resolvers.

[00:06:45]
For this resolver on pet, you can only send an ID, everything else, I'm either gonna throw an error, or I'm just gonna ignore it, right? You will do that in your resolver 100%. But then you gotta ask yourself, do you want to allow your GraphQL schema to let people know that you can do something when your resolvers don't allow it?

[00:07:07]
So, you gotta the point where you stay true to your schema. Like if your schema allows it, then you should support it. And if it doesn't, then you should change the schema.
>> Speaker 4: Can you pass in more than one value to match?
>> Scott Moss: Yes, you can pass on more than one value.

[00:07:24]
So, what do I have for, what's on the pet type? Input, a name, so I pass in a name here, my God, go away. So I pass it a name that I don't have like, this is, I know Moose is the dog, but I'm asking for a cat, so let's see what happens.

[00:07:45]
Nothing comes back.
>> Speaker 4: Not to filter parameters simultaneously. What I'm saying is cat or dog, or name one or name two.
>> Scott Moss: No. Not in this use case, no. The very generic simple Davis sensation that I've built as an abstraction, does not support that. But, yes, that is possible, a lot of GraphQL API's is a support, ors and ands and different combinators like that.

[00:08:14]
Are GraphQL API supports that, and a lot of the GraphQL API support that, It really depends on if you want a support in your resolver. But yeah, you can do that. And that's when it gets really crazy, where it's like, do you want the inputs to be so specific, like for instance, if you had a cat, and you have all these fields, are you gonna make an input for every single field, for instance, the field is a number.

[00:08:40]
You'll have to say input dot age dot greater than, or input dot age dot less than. So there's a strategy on how you determine that, and the community has come together, and they've created standards on how to define those resources on the GraphGL API. So there are standards to defining inputs for resources that you can do things like that.

[00:09:02]
I'm pretty sure Prisma created one. I forgot the name of it. I'll find the link to it, they have whole website, it's like, here's how you should build a GraphQL API, if you need this flexibility, because otherwise you're gonna be sited there, thinking for a long time how to do it.

[00:09:15]
Hasura, the thing that I showed you instantly, also has pretty much the same thing. They do it slightly differently, but if you look at their docs, wherever their docs are, I don't know where the link to their docs are. Wow, okay. They're docs are around here somewhere. Look at their docs, you can see how they generate their API's.

[00:09:34]
And you'll see notes talking about it. They have very specific filtering rules based off on fields that exist on your schema. So they're extremely well typed. So, good question.
>> Scott Moss: Any questions on input, types, and arguments. Yes?
>> Speaker 6: Assuming you can make custom scalar values for these input types, it's like you can define custom scalars for.

[00:09:57]
>> Scott Moss: Yep
>> Speaker 6: So you have some crazy query language, you kind of want to invent, or adopt. You can make a scalar that defines, that has to conform to this kind of string specifications.
>> Scott Moss: Yup, 100%, as long as there's a scholar, the input can use it. Same thing goes with the type, and you can make anything a scholar.

[00:10:15]
Like I said, you can make and adjacent screen a scholar. I mean there's literally nothing you can't do with a scholar, cuz a scholar basically an object that has some functions on it, that get executed when GraphQL is trying to resolve a scholar, or parse a scholar, or get it ready for execution.

[00:10:34]
All you gotta do, is just define those functions and it's up to you to do whatever you want in those functions.