Query Types

[00:00:00]
>> Scott Moss: All right, so now that we have some context on how a GraphQL server is made and how it's built, let's dive a little deeper. First thing I want to talk about is the query type. So as a reference, let's just go back to what we have here, a query type is this, right?

[00:00:15]
So we talked about types or what you will also hear them referred to in the graphical communities object types because they are literally definitions of objects or nodes that your API can expose. So a query type is just a special type that the GraphQL server is expecting to have, there's nothing special, there's nothing else you need about the query type other than the fact that GraphQL expects it to be there to expose data.

[00:00:45]
Other than that it follows the same rules as every other type.
>> Scott Moss: So like I said, it's a type on a schema that defines operations clients can perform to access data that resembles the shape of other types in the schema, which is exactly what we did. So we had to type, it defined a field that its value is expected to be the shape of another type that's defined in our schema.

[00:01:12]
You can also put scholars here I mean, you can say a query just returns a string, there's nothing wrong with that. If I were to do that and execute this query or let me run this again and go back to playground, refresh this. If I were to do this, but keep this query asking for an object, I'm gonna get an error here because it's saying the me field must not have a selection since string has no sub-fields.

[00:01:41]
So, me doesn't return an object anymore, it just returns a string. And the reason it still brings, I didn't change the resolvers to actually return a string, the resolvers are still returning an object. So you can see GraphQL really is very touchy about following the rules of your schema, it's very strongly typed so nothing is gonna work unless you obey those rules.

[00:02:01]
So Creating Queries, we already walked through it super fast but in more detail it's actually just as simple as us walking through it. So the first thing you do is you create a query type in the schema definition language which is exactly what we just did and then you add fields to the Query Type.

[00:02:18]
And then the next thing is you have to create the resolvers for the fields. So we talked a little bit about resolvers and kind of the functions and how they're supposed to resolve a data. But other than that, that's all you have to do to create a query.

[00:02:33]
It's just that if you have more queries here then you would add more fields. So if I want to say, to get me as a user, to get, I don't know, some friends, you could say friends turns an array of users like that. There's no limit to what you want to do as long as you respect the rules of the schema that you created, so you can use scholars, you can use types.

[00:02:56]
And as long as your resolvers were named exactly the same and return the respective values, then you can do whatever you want. That's your schema so there's no limitations there. Yes?
>> Speaker 2: If you have a response that has kind of complex data structure with side loaded models but you have to create intermediate schema to iterate, what's the word here here.

[00:03:26]
>> Speaker 2: Model, to define like say a user's friend, jobs, and pets.
>> Scott Moss: Yeah.
>> Speaker 2: Paternal side load where you create a model that define that response?
>> Scott Moss: Yes and no. It's, so that's a really good question. Wow, you can think it, I like what you thinking. So, yes, you can.

[00:03:45]
And there's a couple of ways you can do that. There's tools that literally will look at like your Postgres database or your secret database or your Mongo database and generate a graphical schema based off of it so that if you really wanted that strongly type nature, you could do it.

[00:03:58]
Or you can use what we're about to talk about the next slide, which is just using the resolvers. So if you think about it, the queries, they don't care how you get the job done, they just expect it to be the exact shape that you say. So if the resolvers need to go talk to another database or another server or something else, query don't care as long as you return it in that shape.

[00:04:20]
So you as an engineer, if you know what it is, then you could hard code that shape, you could transform it yourself. There's a lot of processes that you can do to get it to be that shape.
>> Speaker 2: You should define that shape in this GQL string right here.

[00:04:35]
>> Scott Moss: For now yes, but if you get to composition and there's another GraphQL schema, you could just piggyback off of that one. But in this case, yes, it has to be defined in a schema somewhere that the server knows about, 100%. There's no way for you to send down a shape that isn't defined in the schema.

[00:04:52]
>> Speaker 2: So you might have types that aren't necessarily defining objects, you're defining response objects.
>> Scott Moss: Yes, in fact, there's really no reason why you would define a type in a schema if you didn't have any intention on it being returned somewhere. Like there's like, why even define it.

[00:05:08]
So like, for instance, you might have schemas or models in your database that you never want a client to hit because it's for like some internal tool. You'll never put that on your schema because GraphQL needs not to know about it. So yeah, if you don't want someone querying for it then you just don't add it.

[00:05:24]
Yes?
>> Speaker 3: I think you already covered this, the bang.
>> Scott Moss: Yeah.
>> Speaker 3: The string and the user array. Is that a required field or what is that?
>> Scott Moss: Yeah, so it's not exactly that it's required it's basically saying, this is a non null field. As in it can't be null if queried.

[00:05:44]
If it is null, GraphQL is gonna throw an exception and say, hey, I got back a null value for email and you asked for an email but it should not be null cuz you put a bang there. That's basically what it is. Yeah, you could think of it as required but, technically it's non null.

[00:06:00]
Which is the same damn thing, right.
>> Speaker 2: An empty string is valid string?
>> Scott Moss: As long as it's not null. Yeah, bossy is bossy is fine. As far as the schema is concerned your resolvers though was, we're gonna talk about have the power to do whatever they want, right?

[00:06:20]
You can add your own validation checks in there. It's just that automatically the rules, automatically GraphQL server is gonna look at your schema to figure out what exceptions to throw based off these rules. It's not going to know about like runtime things, like if this is end of string, it doesn't look at the values like that.

[00:06:40]
So you have to do that in your resolver or you can teach the GraphQL server that hey, because this is MD I wanna throw it right in here. So you can teach but by default it wont do for you automatically.