This course has been updated! We now recommend you take the API Design in Node.js, v4 course.
Transcript from the "Non Scalars" Lesson
[00:00:02]
>> Scott Moss: So non scalars and nested resolvers. A non scalar again, a refresh on that, is a custom type in GraphQL. Literally anything that's an object. If you make an object, it's a non scalar, that's basically it. It can be used whatever scalar types are used. So scalar types, again, include strings, integers, floats, ID's, enum's, and Boolean's, those are all scholar types.
[00:00:28] So wherever you can use those, you can use also use non scalars, you just have to resolve it. And like I said before, they have to be resolved eventually. It doesn't matter how nested you go, eventually you're gonna get to the end of the tree and it better resolve that non scalar, otherwise it's gonna freak out as you saw what we just, as you can tell from what we just saw.
[00:00:50] Any questions on non scalars? So in our app, what are the three non scalars that we have?o
>> Speaker 2: Songs, playlists, users?
>> Scott Moss: Yep, song, playlist, user, exactly, everything else is a scalar. Nested resolvers or it's a nest resolvers, basically it's used to create a graph in your graphql API.
[00:01:12] So, as you start resolving, basically you create your schema, you look at the non scalars, and for each thing in your schema like this. I'll just show you, you gotta kinda plan it out and you can plan out how people are gonna interact with your API. So for instance, let's say playlist also resolves curators, the people who curated this playlist, all right, and it's an array of users, right?
[00:01:41] Let's say it's that, but then like let's say on the user GraphQL, you have like, the user has something, an array of all of the playlist that it created or curated, right? So now it's like, you can get the same information on both, right? So you got to kind of plan out how you want to implement this.
[00:02:01] So, if this was the case, what you would do is you would have to write a resolver for this property that would know how to go to the database given this current playlist and find the users that curated it. And then on this side, you would have to go to the database and find the playlist that this user curated.
[00:02:20] And depending on how you save your data and where it is, it could challenging or it could be easy. So you gotta kinda figure out how you wanna do it, but either way you have to create some type of nested resolver that's relying on some other branch, and then that thing may have a nested resolver.
[00:02:33] So for instance, this is where I said it can like get kind of recursive, cuz think about it, let's say I query the user and I say, give me the playlist that you curated, right? And then, inside that playlist, I'm like, give me all your curators. And then, for those users, I say, give me the playlist that you curated.
[00:02:50] And now it's going back and forth over and over and over again. Does that make sense? You can do that forever, somebody could literally just do that to your app and just kill it. So you would have to figure out some strategies on how to avoid that. And there really aren't any good strategies other than, just don't put them on both sides, you know?
[00:03:09] Just don't do stuff like that. There's ways you can like, like for instance, you have that root value that you pass out or that context object. You can pass stuff down there, to give the next resolvers some information on how deep you've been so far and then like maybe cancel if you go like, you know, ten levels deep just stop or something like that.
[00:03:23] There's some things you can do but the best thing to do is better planning, better data modeling, don't allow people to go access stuff on multiple places and reference each other. Like that would be a bad design, these two things reference each other, so therefore you can keep asking for them infinitely until your app just freaks out.
[00:03:42] Do you guys see the fallacy in that? Yeah,
>> Scott Moss: But, in our case we don't have that, we only have, the only one we have right now is playlist and songs, as an example I just showed you. And for the example, I've added the ability to get playlist for a user, which if playlists have songs, and a user has a playlist, now you can go to a user, ask for the playlist, and for each playlist you can get all the songs.
[00:04:10] So you should be able to do that, but that's pretty cool because we didn't build that, all we said was that this user could get playlist and because playlist can get songs now, you can get songs from a user. So that's the whole point of the graph effect, like you didn't put it together like that, whereas the rest you would have to put that together.
[00:04:24] You had to say, I'm gonna make a route where you can go and get the playlist and I'm also gonna give you the songs. It's a predefined thing, whereas this is not predefined. I can create this whenever I want and the way it resolves, because the type resolve each other, it eventually creates that shape for me.
[00:04:39] But it wasn't created that way, they don't know about each other, you know?