Relationships

[00:00:00]
>> Scott Moss: So relationships. I saw some people downloading this earlier, I think they saw it coming, how to link pets with users and users with pets and so forth. So in our database, there is no relationships. But we want to virtualize those relationships with GraphQL and this is where it gets really powerful.

[00:00:16]
And this is where you end up in the place where people will dedash you or stuff like that. So it's like super powerful but at the same time very dangerous. This is basically the graph in GraphQL, so saying that, let's talk about thinking in graphs. So your API is no longer a predefined list of operations that you always return the same shapes.

[00:00:37]
So for instance, like in REST, you have to literally create all the routes, with these verbs, and these parameters, and maybe these query strings and they're predefined ahead of time that's the only thing your client can do. Well, in this graph implementation you have no idea how someone's gonna access your server and instead you just say, here are these nodes they look like these.

[00:00:56]
Here is the connections between these nodes, they exist here, do whatever you want, in fact, you can do whatever you want. And it's that way all the way down, no matter how deep it is, no matter how many nested node you have, it's going that way all the way down until you hit a scholar or some primitive value, right?

[00:01:13]
That's how a graph works. So friends can have friends, they can have friends, they can have friends, they can have friends, they can have friends. All the way until you don't want any more friends to show wherever that is. But they they can be cyclic. They can be recursive.

[00:01:27]
They can be all of those things. So because of that, yeah, I mean, could you imagine writing a controller on your database to resolve a REST throughout and it was recursive? It just went on forever, like probably not a good idea, I probably wouldn't do that, so that's why people use Graph databases.

[00:01:43]
So instead, your API is a set of nodes that know how to resolve themselves and have links to other nodes. This allows a client to ask for nodes and then follow those links to get related nodes. And that's basically nodes and edges inside of graph, and that's the graph in GraphQL.

[00:01:57]
And we're about to experiment with some of that. Any questions on that when I'm even like thinking and graphs, because I think that's the biggest hurdle for people when they switch over to GraphQL it's they're thinking, well, how is someone gonna access these data and he doesn't have to do this, like no, you don't have to think about it.

[00:02:15]
You don't have to think any of it. Just make a resolver that resolves the field. And as long as all of your fields are accounted for, automatically or directly by you, you're good, you don't have to do anything else. And so you have performance issues and even then you're not worrying about specific queries, you are worrying about every query [LAUGH].

[00:02:33]
So there's not one scenario you're concerned about. You're concerned about the generic possibility of all the scenarios and that's what you have to account for.
>> Scott Moss: So adding relationships, how does this work? So you can add a type as a field value on another type. And then you can just create resolvers for those fields on the type.

[00:02:52]
It's that simple. So if I were to come here and so I have a user and I have a shoe. I can say users, you could see I already have this one here for friends but I'm gonna do shoes now. Users have shoes, and exists as shoe, and it's not null, right?

[00:03:11]
I can also go the other way around and I could say, a shoe has a user, and its user is not null. And I want my database doesn't have to reflect this. My database doesn't have to have, this one too many relationship that I just described inside of my graph field schema.

[00:03:28]
Doesn't need to know about it at all. Because we're virtualizing and we're gonna do all this with inside the resolvers