This course has been updated! We now recommend you take the Advanced GraphQL, v2 course.
Transcript from the "Code Repository Walkthrough" Lesson
[00:00:00]
>> Scott Moss: So all right, let's just dive right into it, let me stop talking. So let's look at our project.graphql, let's get a little quick tour here. Basically we have a type that's a project, it's got some fields on it, nothing too crazy here. One thing to note though, on line 7, is that project is referencing another type called task.
[00:00:21] That's not a built in GraphQL type, that's a custom type that we made. So because of that, we can automatically think right now, we're probably going to have to resolve that, right? How does a project know what a type is? Unless your database was set up exactly like this, which, most of the time it's probably not.
[00:00:40] If you're using a SQL database you could imagine project as a table, task as a table. So there's no way that it's set up like that, so you're gonna have to resolve it somehow. So that's just something to think about. But basically we have this type project, we have these inputs, we have some basic queries to get one project to get many projects.
[00:00:57] And we have a mutation to create a project. So it's nothing too complicated here. Now when we get into these resolvers, let's look at how we could resolve a couple things here. We're gonna look at how we can resolve some of these fields maybe, and then we're gonna look at how we can resolve some of these queries and mutations.
[00:01:15] So let's do that. So let's hop into the project resolver. I'm gonna scroll down to the exports here. One thing I wanna do is talk about this. This is something we didn't talk about. Now if you've used GraphQL before, you might have seen, you kind of probably know what I'm doing here.
[00:01:33] But basically, before what I showed you is only how to write resolvers for a query or mutation, but what is this? Why am I resolving a project here? I thought a project was a type, right? So how am I resolving a type? Does anybody know what this is for?
[00:01:55]
>> Scott Moss: Yes.
>> Speaker 2: So you resolve a specific field on the type.
>> Scott Moss: Exactly.
>> Speaker 2: Just on the input value.
>> Scott Moss: Yeah, it's how you resolve a specific field on a type, so it's actually no different than a query mutation. Whereas a query and a mutation are both types, and we're resolving their fields, project is also a type in which we can also resolve their fields.
[00:02:14] Now the way this works is, by default, GraphQL will automatically resolve to a field that has a matching property on the object that is returned, right? So if I returned, so let's say if I go to Query, and I run this ProjectQuery here. And inside of its resolver, which is here, if this object had a name property on it, GraphQL will automatically resolve that for me.
[00:02:38] I don't have to write a resolver for it because the properties match up, exactly the same. So basically if there was a project.name here, there was a name property on this project. This name field would automatically get resolved for me. I don't have to do anything. I can, however, override the automatic resolution and write my own resolver for name, here.
[00:03:00] And this is what this is for. So this is saying hey, whenever someone asks for a project and they ask for one of these fields, this is how you resolve that. But by default, if it already exists on the object, it will automatically be resolved. Now because we're using Mongo, Mongo doesn't have an id property on this document, it has an _id.
[00:03:20] So but if you look at the project type, it's asking for id. So by default, if you were to ask for id, and we can check right now, it won't resolve it. It will be like, I don't know what id is, you never told me what that is.
[00:03:33] It will just be null. And if I put an exclamation mark in front of it, it will just break. So I have to write a custom resolver to tell GraphQL how to resolve id, and the way I do that is like this. So let's just walk through it.
[00:03:48]
>> Speaker 3: Real quick.
>> Scott Moss: Yes.
>> Speaker 3: Do you plus string to cast as a string?
>> Scott Moss: Yeah, that's what I just did.
>> Speaker 3: Okay, all right, interesting. So what is it, actually?
>> Scott Moss: This?
>> Speaker 3: In JSON, what type is that?
>> Scott Moss: So it really depends how you query the database.
[00:04:03] So with Mongoose, if you just query the database, and you don't do a lean, it basically returns an object. And then that id fills what's called an object id, which is really an object. It looks like an id. When you log it, it just calls two strings on itself, so it looks like a string.
[00:04:15] But if you were to do type of in front of it, it's actually an object, right? So this is just casting it to a string. This is probably not the best way to do it. This is just an example, but you would probably do this on the schema level.
[00:04:29] You would make a virtual field on Mongo itself and say, hey, I wanna add a virtual focal ID that casts _id to a string and you would do it there. So you can benefit from id everywhere else outside of GraphQL. But this is a really good example for this.