This course has been updated! We now recommend you take the Server-Side GraphQL in Node.js course.
Transcript from the "Relational Data" Lesson
>> Scott Moss: So now that we know that, and this result is only executed when the query demands for them, when we started some relational data like an owner. And we say the owner we wanna get the name, and we run that. This gets back layered, okay, so how does that work?
[00:00:18] So let's clear the console out and follow that step by step, cuz it's a little more complicated So we'll run it one time, and then we'll go look at these logs. So the first thing that happened is, I executed the query called, Cat, and we logged into Cat Query, right?
[00:00:33] Boom. Then that return to blank object, which is supposed to be a cat type, but we're not done yet, so the server's gonna trust us until we're done. So if we go look at our resolver that ask for a name, an age and owner for the cat type, and look, I have resolved for the name, age and owner.
[00:00:50] So it execute all three of those functions. So the first one was name, that's why it says in cat name. The second one was age, that's why it says in cat age. And then the third one that I asked for was owner, and that's why I said it's in cat owner.
[00:01:03] So that happened, and then because the owner is an object type, I just returned a blank object, and this is supposed to be an owner type. So just like it looked up the fields for the cat type, it went to go look up the fields for the owner type.
[00:01:15] And the owner type, if you go see what I asked for there, I asked for a name. So then it executed owner dot name. And hat's why it logged in owner name and then it returned that value. Anyone need a further explanation on that? That one is a little more complicated.
>> Speaker 2: Can you go back to the-
>> Scott Moss: Yes, go back to the query. Yeah, so you can see you asked for the name, the age and then owner, which all have their own resolver functions. And then the owner.name also had its own resolver function, right? So if I go back up and I say okay, give me the cat for this owner and I give you the name of that cat, you could see it still works, right?
[00:01:56] And the reason that still works is for the same reason that the other ones work, because a owner has a cat resolver here. And it returns an object which is the cat type. So then it goes and look back at the cat type, I'm like all right okay cool.
[00:02:08] How do you get a name for a cat. You just return Daryl. That's how you get a name for a cat. So we can go on and on and on here. I can say cool, give me the owner, give me the cat. Give me the owner, give me the cat
>> Scott Moss: And then finally I can say cool, just give the name of whatever that one is, and it will give it to me.
>> Scott Moss: This starting to make sense? Okay, it's a little weird because when you make APIs before, you don't give the clients this possibility. You don't let them do this.
[00:02:44] The API says, this is what you get and this is what you get, and the clients had to get it. Whereas now, the client's like this is what I want, and API's like, all right, I have fulfill every possible combination of what you want. And that's why it has to be strictly typed.
[00:02:57] You have these strict type definitions to set the bounds of what a query can do. And because it is strictly type, you can pretty much guarantee what will and what will not happen because it's strictly type. It's finite, it's not some world of possibilities. There's only so many things you can do because of the way that you developed the schema.
>> Scott Moss: So any questions on this?
>> Scott Moss: Okay, and you can see this goes on and on forever. And eventually, you would replace these with database queries, so imagine if all these were asynchronous and hitting the database every single time. So this query wouldn't execute so fast, I'll tell you that.
[00:03:36] So there's different ways to get around that, and we can talk about that later.