Data from the Database

[00:00:00]
>> We're gonna get our database hooked up. We're gonna wire up. Instead of returning purely fixture data, which we are right now. Just remember in our resolver query resolver we're returning this fixture data for suggestions and this fixture data for the current user. Let's actually get this returning something from our database.

[00:00:24]
So, this should be pretty easy. We're going to replace the existing suggestions resolver with this, get all suggestions from our database. And because we've typed this really well and we have this context object, we'll be able to grab this little DB variable with ease. And we'll know this is working if we see more suggestions in the UI.

[00:01:03]
Well, let's use our dev tool first. That's a good sign, we see four things now instead of two in the UI. See four things here, so this is now data coming from our database. And then for our current user, we can do something similar. So what we're going to do here is grab all users.

[00:01:29]
We'll use destructuring assignment to get the first one in the array. So we'll consider the first user to be the currently logged in user. And if it's empty, there's no first user will throw otherwise we'll return. The reason we have to do that not only is it good to give us an actionable mode of failure here, right, with a good error message, but this is not a nullable field like current user if asked for has to return some value.

[00:02:00]
So if there's a possibility of this being null the both the type checking and Apollo's run time validation should yell at us about it. We can explore that here in a sec. So I've just replaced the existing resolver with the new one. Let's test it real quick. Okay, that this just changed here.

[00:02:32]
Let's get the creation date. Great, it's March 23rd. So it was yesterday. So this is data coming from our database. I don't think that the UI will change much here cuz the fixture data is in fact the same thing. But you can see this switch back, it's no longer John Doe.

[00:02:55]
So let's see what happens if we remove this. So now we're getting yelled at a little bit like DB user or undefined is not assignable to the type that was generated for this resolver. So this is where we're kind of being told. Hey, this is not supposed to be a nullable thing, like you're supposed to always return something here.

[00:03:20]
So where we are right now, is, we have type checking working across our tech stack now. If we wanted to maybe make this nullable, all we'd have to do is go to our schema.graphql. Remove this exclamation mark. It's gonna make our UI angry, by the way, cuz it expects current user to be there.

[00:03:42]
But let's go back to our server sub project, run our codegen again. And we might need to bounce the TypeScript server, the language server. I'm not sure why this is allowed here. What if I return null? Yeah, okay, it's willing to tolerate null not undefined, but if I put this requirement back and kojin again, it should reject to the null.

[00:04:27]
Yep, it already is. Null is not assignable to that type now, so you'd have to put this back and then add the guard to handle the possibility that it's not there. So we can see the guardrails are up where we're being protected from. There's one set of assumptions and one set of constraints that both our UI and our back end and our data persistence, like serialization and deserialization.

[00:04:57]
All of that is operating under the same set of assumptions that are defined in one file, which is a great place to be.