This course has been updated! We now recommend you take the API Design in Node.js, v4 course.

Check out a free preview of the full REST & GraphQL API Design in Node.js, v2 (using Express & MongoDB) course:
The "Nested Resolvers" Lesson is part of the full, REST & GraphQL API Design in Node.js, v2 (using Express & MongoDB) course featured in this preview video. Here's what you'd learn in this lesson:

The magic graphQL is in being able to nest resolvers and continue to resolve more data into the response as the user requests more data in the GraphQL query. You can avoid resolvers from running altogether if the user doesn't need that data that the resolver provides.

Get Unlimited Access Now

Transcript from the "Nested Resolvers" Lesson

>> Scott: The second thing is, and we're gonna get to in a minute, is nested resolvers. And nested resolvers are basically like this. So let's say I want to, let's go back to our user here, let's say I want to resolve friends. I wanna get a list of friends for my user, and they're all just gonna be strange, let's keep it simple for now.

[00:00:26] And it's a nominal array. Do I have friends anywhere on here? Sure, I could just add friends. I can just add it right here, right? I can just put in friends and it would totally work. But we're gonna use a nested resolver here to resolve this, assuming friends come from the database somewhere.

[00:00:42] If we were to resolve friends here, we would be very wasteful. That's because we only want to send back the friends when someone asks for the friends, right? And if we were to resolve the friends inside of this resolver, we would never know if you asked for the friends, unless we looked at this AST which I said that you should never look at.

[00:01:05] So we could rely on GraphQL to determine if someone asked for a friend. And we can do that by setting up a nested resolver. So a nested resolver's only gonna run when someone asks for that field, right? So if you didn't ask for the friends field, this function that we're about to write won't even execute, so it's not wasteful.

[00:01:21] But if we'd executed it up here, it's gonna run every single time, even though you didn't ask for it. So if we come down here if we want to write a nested resolver, we want to write, we want to tell GraphQL how to resolve the friends field on the user type.

[00:01:34] So just like we tell GraphQL how to resolve the getMe field on the Query type, we would do the same thing. So for the User type we're gonna tell GraphQL how to resolve the friends field.
>> Scott: Does that make sense? So knowing that, all you gotta do is write a function and the syntax is exactly the same as this, rootValue, arg, context, info.

[00:01:54] Now remember when I said nested resolver that rootValue's actually gonna be something? In this case it is. It's gonna be the branch from which it branched from. So where did this friends branch from? What is the type above it?
>> Speaker 2: User.
>> Scott: Exactly. So this first argument is user.

[00:02:09] It's the user that these friends belong to. That's the root value. The second argument is the same args that may have or may have not been passing. In this case, there are no args, but guess what, you can pass in args to fields. It's pretty crazy, you can totally do that.

[00:02:23] There's nothing stopping you from saying, this friends also takes in sorting. I want to sort these friends. You can totally do that, and those args will be right here.
>> Scott: But we're not gonna do that. So you'll have args here. We don't need args. And then now that we have that user, you would say, okay, cool.

[00:02:39] Query the DB for friends of this user.
>> Scott: Right? But we're just gonna return back an array of strings.
>> Scott: Cool, so that should satisfy our schema which is just an array of strings. We're just returning an array of strings, right? So now let's actually execute this. And you refresh the graphical, so we can make sure that that worked.

[00:03:14] So if we look at Query, we click at User, we see friends there now, which is an array of strings. And now if I say, I wanna getMe.
>> Scott: So getMe, I wanna get the ID, I wanna also get friends. And if I hit that, you can see, I get back my array of friends.

[00:03:36] Now, I'm just gonna show you how this works. I'm gonna put a log in here. This is a very important part.
>> Scott: We'll put a log in here for in friends, and then when I run this query with the asking for friends, you can see that the log definitely runs, it's in friends, okay?

[00:03:54] Now I'm gonna clear the log. I'm gonna get rid of friends. I'm gonna run this query again. You see it doesn't log in friends. It doesn't even go to that function. That's the important part. That's what's so beautiful about this, I think. That way you're not wasteful. It only goes to the thing when you ask for it.

[00:04:13] That's why you wanna put things in nested resolvers, and you don't want to treat your resolvers like controllers. I'm gonna put everything in this one controller. I wanna grab the whole thing at the database. I'm gonna give it to GraphQL, and let them figure out what properties they need.

[00:04:24] That's extremely wasteful. You definitely wanna use the nested resolvers to let the user decide when you should be creating and when you shouldn't. It's way more flexible. You can create a more flexible graph using that approach. So once you have those resolvers you just export them however you want and then, I'm sorry you actually have to export them like this.

>> Speaker 2: Okay, I'm almost done. I was like dang, that's a bad way to queue him off the stage.
>> Scott: All right, I'm wrapping up. So you export those resolvers, and then you can see right here in the index here, I'm sorry, where was that, resolvers.

>> Scott: We export those resolvers into here, right? We have user resolvers, and then now here we're just merging them together. So merge is gonna merge them all together. So eventually we're gonna have objects that looks like this with a Query property. It's gonna have every single query that we ever made for every single query.

[00:05:25] And then we'll have a mutation when we get to mutations.
>> Scott: And it's gonna have all of our mutations that we make. And then all the other ones after that are gonna be nested ones. So here's the ones for user. Here's the one for song. Those are all gonna be the nested ones.

[00:05:39] So that's what this merge is going, it's putting them all together. But eventually it's gonna create that for us.