Resolver

[00:00:00]
>> So we just did our test query, we saw that that failed. So let's proceed to the next step. What we're gonna need in order to actually give GraphQL, give Apollo some data to emit, well, we'll have to create something called a resolver. And the job of the resolver is effectively to gather things together, maybe reads the equivalent of path params or query params, or it reads things that are part of the request coming in.

[00:00:31]
And then it produces pieces of the data that are organized into the response. If you've ever used something like redux, you can think of these kind of reducers, where you have these little subparts that handle a little piece of state, but then the way everything is organized together, it's sort of done at a higher level.

[00:00:55]
So in a reducer, maybe you're just adding a new number to an array, and that's one little thing. But in the bigger picture, this array is deeply nested into this one little spot. So we don't have to worry about creating this payload that eventually the consumer of the API gets, we can just worry about dealing with this one little field.

[00:01:18]
So let's create our first resolver. To create our first resolver, we're going to need to go back into our ApolloServer TS file. And because we're gonna end up using this database now, we can remove that underscore that was telling TypeScript to not worry about the fact that we were leaving that variable unused.

[00:01:40]
So let's go ahead and do that first. So here we go. We'll go up to the top. We'll delete that underscore, now TypeScript's gonna nag us, we'll take care of that in a moment. Next, we're gonna insert this code somewhere before we create our instance of ApolloServer, why?

[00:01:58]
Because we're gonna pass this in to the ApolloServer constructor. And this is our first resolver. And you can see here we have this as a top level property of this object, query with a capital Q. And you may recall that in our schema, right, that GQL string with backticks, we also had a top level thing called query.

[00:02:21]
It was a type query. We can go here and look at it, right here. So the resolver kind of should match one to one, at least with this query type. So we've got currentUser and we've got suggestions. And currentUser returns a user. Suggestions returns an array of things, right?

[00:02:42]
That's what we see right up here. So we're creating the equivalent to that, something that matches up nicely with our schema. So let's grab this and let's insert it right above our ApollServer instantiation. And then we're going to add this to the arguments passed into ApolloServer. It's into this single configuration object.

[00:03:16]
We're also going to add this function here called context. So I told you that this context object, this is by the way, it's kind of an express concept, but it carries through to ApolloServer as well. It's just this object that's always available in any of our resolvers, right?

[00:03:37]
Any of these little functions, context is one of the arguments that you get. So in this case, if we have our database, this gives us a nice little convenient handle to grab our database and it's right where we need it. Later we're gonna use this for any cached records that we need to put someplace where we have things that might cascade through multiple resolvers.

[00:03:59]
Where maybe we get a tweet, and then we have to in a separate function get the author for a tweet. Anything that we wanna save, like some work that can be reused, we might also store that on this context object. Now this can be either an object or a function that returns an object.

[00:04:18]
There is a significant difference between those. If it's just an object, that object remains the same for the life of your application. And what that means for you is if you're using this as a temporary scratchpad of sorts, things will be left there between requests, right? So let's imagine that you use it to hold temporarily some calculated result, maybe a count of how many times a thing has happened.

[00:04:47]
At subsequent requests, you might find that, you're not starting with a 0 you're starting with 10, because we've already counted up to 10. So if you have a function that returns this object, you get a new one each and every time, that's an important difference here. And in this case, we kind of want this to be on a per request basis, a clean slate.

[00:05:09]
If we were to store, for example, information about a user here, but they're off token, you would want some guarantee that this will get thrown away, it won't leak between requests. All right, so let's paste this in, resolvers and context. Resolvers and context, save. And let's go back to our GraphQL dev tools, And let's see what happens.

[00:05:41]
I'm gonna just run the same query again. Let me make this a little bit bigger so we can see it really well. I wanna run the same query again. And look at that, no more error, we're getting that fixed your data, right, coming through. Another advantage to GraphQL, I can combine the retrieval of two different kinds of things into a single request.

[00:06:10]
I can get this list of suggestions as well. Now in this case, it's gonna be an empty array. But this is another advantage over a REST API design. You don't need to make n requests for n resources. This in fact was a key reason that GraphQL or key problem that GraphQL solved for Facebook, where this was around the time where they were rethinking their mobile strategy.

[00:06:36]
And for their native iOS and Android apps, the number of requests they were having to make to assemble everything on the Facebook page, like messages and feed items and photos and all of this stuff, there's so much going on. And the more they broke things up into micro services, the more they found that they were making dozens and dozens of requests just for that first page load.

[00:06:59]
So this lets you kind of combine everything into one big pile, you get everything that was asked for, you return it all at once. And this reduces bottlenecks, like the number of concurrent connections that can be made. Or situations where multiple round trips are required in order to assemble something, makes it real nice and easy.

[00:07:22]
So great, we have a GraphQL API now. That was hopefully not too painful.