Advanced GraphQL

Advanced GraphQL Nested Resolvers Exercise

Topics:

This course has been updated! We now recommend you take the Advanced GraphQL, v2 course.

Check out a free preview of the full Advanced GraphQL course:
The "Nested Resolvers Exercise" Lesson is part of the full, Advanced GraphQL course featured in this preview video. Here's what you'd learn in this lesson:

Scott shows that, when given a query, the types and resolvers need to be created, so the query executes correctly.

Get Unlimited Access Now

Transcript from the "Nested Resolvers Exercise" Lesson

[00:00:00]
>> Scott Moss: So now that we know the order of operations that was ours. We know arguments and we know that we need to write them in such a way that they only return what they're supposed to return. I'm gonna give you a query, and then you're gonna write the resolvers to make that query possible.

[00:00:18] Now this is the only exercise that's actually gonna require you to do some type of Mongo. So if you don't know Mongo that's fine, just look at the other resolvers cuz you're pretty much gonna be doing the exact same thing. The thing to remember here is that the models are on the context object, so context.models.

[00:00:37] But there's only two, there's project and then there's task, there's only two models that's on there. And then most of what you'll be doing is you'll either be doing a find, or a find by ID or something like that. And arguments are pretty similar, you can look at them, and if you get stuck I will help you out if this is your first time in Mongo.

[00:00:55] You do not need to know Mongo to do this but can't avoid it for this exercise because you got to write the resolvers. I'm not gonna write the queries for you, you're not gonna learn that way. So basically, if you go and you check out to lesson two.

[00:01:06] If you go into project.resolvers@js you'll see on this line right here it's a different line than you because I wrote some code. You'll see something that says, resolve some fields here, that doesn't mean anything right now cuz I haven't given you the query. This is where you're gonna be writing some code, resolve some fields here.

[00:01:23] And then inside of task, task revolvers, you scroll down and there will also be something in line for you that says resolve some fields here. Now what are those fields? I'm gonna put this query on this page, I'm gonna pause it then you gotta get that query to work.

[00:01:43] And that's how you have to think about how you made grapulate the R. So at least that's how it, I start with my client or whatever's gonna consume the API. I write the query, and I'm like cool, how do I resolve that on the backend? Because it's really about how do you get the data to the client, it's about how it needs and how it needs to consume it.

[00:02:01] So from that perspective, you push everything to the backend, you let it to do it's work and then by time it comes to the front, it's exactly the way that it needed it. So this is a good example of just like designing GraphQL APIs in my opinion. All right, so what I want to be able to do is, I wanna be able to grab a project by an ID, so,

[00:02:29]
>> Scott Moss: What is it, projects, inputs? Actually, let's do a full query here, call this Projects, take an input of ProjectInput. And then what I wanna be able to do is grab a project by the input, and that's gonna take input. And I wanna get the name of the projects, then I wanna get all the tasks associated with the project.

[00:03:03] And I wanna get the ids, name of those task, then I wanna get the project of those task with the name of them. Now if you look at this you might think like the project of this task is the project before it, right. Cuz I'm asking for this one project first, and I want the name of that project.

[00:03:27] And then I wanna get all the tasks associated with that project. And then I wanna get the project associated with each one of those tasks, which would be the project that came before it. And this is what I was saying, it can go on and on. I could just go on here, I could like yeah, do this again.

[00:03:41] And I just keep going on and on and on and on. And this will just be the most ridiculous query and it will break your system. It will totally break your system cuz it's exponential every level you go, right. If you had 100 tasks, every level I went down it's exponential every single time, it's like n squared.

[00:03:59] So, yeah you're system would crap out. Even if you had cache, it eventually would just crap out. So you got to find ways around that, but basically this is what you're going to make it. We're not gonna go that deep, so you need to be able to resolve this.

[00:04:13] Most of this is already done for you, like this project query is done for you. Like these IDs, these names are done for you. What you're gonna be resolving is most likely this array of tasks. And then this project field on the task type, that's what you're probably gonna resolve.

[00:04:30] The thing to note here is that you probably don't have any projects or tasks in your database. So how do you know if this works, well, you need to crate some first. Open a new tab and write a new mutation and create some projects and tasks, and how do you do that?

[00:04:43] Well, you got this handy-dandy schema right here that tells you exactly how to do it. So if I wanted to make a new project, I can see that a need to run a mutation called new project with this input, and that's gonna create a project. And then if you wanted to create some tasks, there's a new tasks mutation here that also says you can make a new task and it has these inputs.

[00:05:04] So, at least make one project cuz you need one, and then at least make two tasks so there's an array of tasks. Maybe you can get away with one task, and then that should suffice,. So at least one project, one task, do a mutation on those two and then you need to get this query to work.

[00:05:20] Yes?
>> Speaker 2: Why would the frontend ever want something like that?
>> Scott Moss: The frontend might want something like this because you can think about it like, yeah, right?
>> Speaker 2: [LAUGH]
>> Scott Moss: You'd be surprised. So the frontend might want something like this because, okay if you have a component architecture that has a component in the component.

[00:05:36] And you just wanna be able to take the data straight from the result and pass it right into another component, right in the template without having to alter anything you would want something like this. And I've actually come into places where I was, yeah, I wanted to do something like this.

[00:05:53] So, yeah, it's repetitive, and you're might think like, that's so overkill. But actually, there's so many things you could do in a database to optimize this, that you're gonna find out that it's so easy, it's like it doesn't matter. But, yeah, you definitely wouldn't want something like this a lot of the times.

[00:06:09]
>> Speaker 3: I've done this a ton.
>> Scott Moss: [LAUGH]
>> Speaker 3: This I'm working on actually has objects that are embedded in other objects. But we need to know about the parent in order to deduplicate.
>> Scott Moss: Exactly, yeah, that's another one, deduplicate, yup, yeah.
>> Speaker 3: Yeah.