Transcript from the "Introducing Resolvers & Setup" Lesson
>> Scott Moss: So next thing we're gonna be doing is we're gonna be talking about resolvers. Again, somebody wanna tell me what resolvers are?
>> Speaker 2: They resolve your data.
>> Scott Moss: Yeah, they resolve your data. If you think about, if you ever build a server in REST, If you don't like model view controller, NVC, whatever.
[00:00:22] You could think of resolvers like a controller, but it's just way more flexible. Whereas a controller, yeah it's just way more flexible and it's way more composable than a controller, I would say. Resolvers do one thing. But they are aware of things that happened before them. And then they can set things up to happen after them.
[00:00:47] And you'll see how that works in a little bit. Whereas controls are just like this is the end all. You run this function and that's it. There's nothing else after this. Resolvers like, yeah, I might execute here but I might execute 20 resolvers later too for the same thing, so it gets kind of crazy.
[00:01:02] So let's just check out to lesson two.
>> Scott Moss: Stash this.
>> Scott Moss: All right, so we'll check out to lesson two. And then, basically, what you're gonna be doing and this is not me setting you up. We're gonna go through resolvers a little bit, I just want to set the context.
[00:01:28] But from going forward with this project the exercise you just did was based off just generic, hello world. But going forward now everything you do is actually gonna be based in the context of this project and it's gonna be real world stuff. There's gonna be an app. We're building an API for an app, which is basically a to-do app, so all the data here is modelled for that.
[00:01:48] There's projects, and there's tasks, so everything going forward is gonna be based off of that. And you can have that in the back of your head, you're building an API for a to-do app, some type of advanced productivity app. So everything we're gonna be doing is going forward for that.
[00:02:02] And basically what you're gonna be doing here is you're gonna be writing not just regular resolvers because that's the first course. In this course we're gonna be writing some advanced revolvers and we're gonna see how that works. But before we do that I'm just gonna walk through in more detail what a resolver looks like.
[00:02:20] Because I already talked about it earlier today before arguments and all that stuff. But I'm gonna walk through more detail, log them out, show you what's happening, and give you an idea of all the tools you can use, and then you're gonna have to figure out how to resolve a query that's given to you, and you're going to have to write the resolvers for it.
[00:02:38] So, first thing first. Let's talk about resolvers and how they work, and how they actually get incorporated with GRAPHQL and the life cycle of these resolvers. So what I'm gonna do is I'm just gonna start this.
>> Scott Moss: On 5,000.
>> Scott Moss: Awesome, and then now you'll probably have, if you were to start this, you would see a way different schema, whole bunch of stuff here.
[00:03:07] This stuff is already done for you. We're just going to be talking about some of the things on the lessons. But basically, we have an API for a to do app and what we need to do is figure out how to resolve specific queries that reference each other.
[00:03:23] So to do that, it's all going to be inside of our resolvers. This part is going to be tricky because you actually have to change how you think of resolving data. These functions are so reusable and you have no control over them. And basically what I'm saying is that someone can give you a query that you don't know of.
[00:03:43] Sure, you design types. You design fields. But when someone actually executes that query, it can be whatever they want. So you need to create a system that allows someone to execute any query that they want, given the bounds of your types, right? So it can be in any order.
[00:04:00] You don't have any idea in what order resolvers might be called. But they need to work in every scenario. That sounds complicated, it's because it is. That's whatever resolver it is that you have to do that. So we need to write over resolver in such a way that they could be resolved from many different places.
[00:04:17] Luckily in this app there is not too many advanced places where you can call them differently. It's only two different places. But in a really big app, you might have a resolver that's being called from ten different types, and these are responding exactly the same way. And you have, you just gotta use the tools provided you to figure that out.