Server-Side GraphQL in Node.js Relationships Q&A

[00:00:01]
>> Scott Moss: Yes?
>> Speaker 2: You said they run in parallel, do they really?
>> Scott Moss: In this example, no, they don't run in parallel. But if you were to send. So I don't wanna say don't, because there is another case where, I don't know if anyone thought of this. But let's say you had, let's think about it like this.

[00:00:27] Let's say you're resolving multiple fields on a type. So we're resolving owner, but we're also gonna resolve pet dot, I don't know, name. For some reason, you wanted to capitalize the name or something like that. I don't know what you're gonna do to it. But you also wanna resolve that name, right?

[00:00:42] Okay.
>> Scott Moss: And you have access to the pet here just like you have access to the pet here, okay? But what if you need it the owner, pet.owner, inside of pet.name, you needed the result of whatever this resolves to inside of this one you can't, because these run in parallel.

[00:01:05] These fields that get resolved for a type, they all run a parallel. So the pet that you see here is gonna be the same pet that you see here before this executes, it's not gonna be the pet that happens after this. So that's why I'm hesitant to say like no.

[00:01:22] True, that those ones in the list run serially, but the fields that get resolved run in parallel because you might catch yourself in a point where you're writing these fill level resolvers that depend on sibling fill level resolvers and it just doesn't work. So I've had to have move forward, I didn't really understand GraphQL.

[00:01:42] So, yeah, just don't depend on things working in a certain order. The only order you can guarantee is that, this is the source of truth. The query that they send up, that's the order. There is no other order that you can guarantee. It's pretty crazy, right? I bet you're thinking like, it will probably be some pretty crazy stuff about this.

[00:02:03] The whole purpose of them creating this is that, imagine if you're writing a client, you're writing something to React or whatever. You can just write a query like this, if you had a component that literally took in only these fields and that's all the needed, it's exactly what they needed.

[00:02:14] Imagine writing a query like this and then getting back exactly that without having to do anything. You can throw it straight in your template and it just works. That's why they made GraphQL, it was made because of that. Cuz you can just take data and throw it in, and you only get back what you needed, nothing more, you got the formatting, you're not doing anything.

[00:02:29] But now, it's expanding towards like all the service type of stuff where it's like, wait, hold on, hold on now. GraphQL is actually pretty dope with the server now, you can go as crazy shit, we didn't think about that. It's really good for like ETO, data pipeline, and all these other crazy stuff, where you got two services that don't know about each other.

[00:02:45] But if you have a strict contract between them two, wait, like a schema, wait GraphQL. So like they're doing stuff like that now. It's a lot different. Yes?
>> Speaker 2: So in the while is it or like in your workplace, it's important that you're building relationships between like these two types like user and pet, because you're trying to build connections using the data for your client.

[00:03:08] Is that kinda like the approach?
>> Scott Moss: It depends. It depends on who your APIs for. If it's a public API, I think you wanna expose different avenues that allow people to do different things, different connections. But internally for our products, we build our schema based off on what the UI needs, right?

[00:03:25] It's usually based off a page. It's like for this page, we need all this stuff. Like if there is a settings page, you might have credit card info, user info, subscription info, and those are all different entities on your database. So you'll make types for all those. And then you'll make a query that might just say, give me this page or you might just make a query that just says, I don't know, give me subscription info and I'll link to something else and you could compose it yourself.

[00:03:53] We normally base it off of UI, because that's the whole point of this.
>> Speaker 2: Yeah, yeah.
>> Scott Moss: We wanna make one call when this page loads up and everything just goes into it.
>> Speaker 2: Yeah, cuz I think why I had that question is cuz you were mentioning how in our traditional rest API, you have to anticipate every combination or whatever they're going to need.

[00:04:10] And so, maybe GraphQL overcomes that by just pre-building connections in the same way,
>> Scott Moss: Yeah.
>> Speaker 2: But maybe what you're saying is, depending on the app, those are the different connections that you needed.
>> Scott Moss: Right, a 100%, cuz I wouldn't just connect everything together. I wouldn't go in like, all right, make it a new type.

[00:04:28] Let me add a field for every other type to reference it. I wouldn't need to do that. It was like, okay. Who is using this type and why do they need it? You'll write the code in your run into like, okay, I'm on the profile page and I absolutely need this thing that's all way over here.

[00:04:43] I can make another query or I could just add a relationship and just do it in one query, right? So basically.