REST & GraphQL API Design in Node.js, v2 (using Express & MongoDB) Exercise: MongoDB Models

Transcript from the "Exercise: MongoDB Models" Lesson

[00:00:00]
>> Scott Moss: So you need to complete the schemas in the resource models and then get the model specs to pass. So every resource, which we only have three right now, which is playlist, song and user, theres a .model file, you need to get them to pass. Now you might be thinking, well, I don't know what to put in here.

[00:00:17] Well if you run the test you'll see that it all fills. The test is descriptive enough to tell you what fields you need and what properties need to be on those fields. So look at the tests. If you want to actually look at the tests, each resource has a .spec file and you can actually read the test, it'll tell you.

[00:00:34] Like for instance, if you look at the song model, it says, a song model should have a title, even though it's spelled wrong. Title, it expects it to exist, it expects the required to be an array. Now, this is tricky, because I didn't tell you how to make an array with required.

[00:00:51] I only told you how to do it with a boolean. So I'm not gonna be a jerk. I'm actually just gonna show you how to do this right now. So right now, before I was like, you can put required true. But you can also make required an array like this.

[00:01:04] And the second argument is the custom error you want to be thrown when this is not validated. So like required true. And you're like, yo, Dogs must have names homie. So that is a custom error that's gonna be thrown when you don't pass it a name. So the test is looking for something like this.

[00:01:23] So it's saying the required validation must be an array. So when that test fails, and you're like, I don't know how to put in an array for a required, I thought it was only boolean, it's talking about this. This allows you to custom error messages. This is something so small but something very helpful.

[00:01:38] If you look at the logs just to see that error, and be like, I know what's going on. If you don't do that, Mongoose will throw the most obscure error. And it'll be like duplicate key, 1100 dup, you're like, what? What is that? I don't know what's going on.

[00:01:50] This is way easier to read, so I highly recommend doing that. So yeah, get those tests to pass. All the model tests should pass. And when I say all the model tests, let me run the tests so you can see what I'm talking about.
>> Scott Moss: You see every single one that has model on it, which are 11 tests, they should all be passing.

[00:02:17] Pretty much all your tests should be passing except for the ones that are in blue right now because they're being skipped. So after you get done with this, all your tests, you should either see all green and blue, and that's it. There should be no red. So again, use the language that I wrote in the test, look at the error messages to kind of figure out what you need to do here.

[00:02:36] You know, I'm not really a big fan of like TDD, I mean who really does TDD? But on the back end I actually find myself doing TDD a lot for some reason. On the front end I can almost never do it. It's just like I just can't. I have to build this feature, I gotta test it out, I gotta check into these browsers.

[00:02:51] And then I'll write code to keep it there. But on the back end I know exactly what needs to happen. There's no fragmentation of browsers, it's gonna run exactly the same in the same run time. So it's easy for me to visualize tests, so I would actually come in and prefer to have tests on the back end, and then build my code off of that.

[00:03:09] So this is good practice for that, so think about. So these tests are done for you, so if you were given these tests as like, here, here's some tests, write the code for this. This is a good assignment for it. I think it works very well on the back end, I don't think it works that well on the front end.

[00:03:22]
>> Speaker 2: It's cuz in the back end it's data in, data out.
>> Scott Moss: Yeah, exactly.
>> Speaker 2: Like here's your data, that's posted.
>> Scott Moss: Right.
>> Speaker 2: Or here's a route, and then you need to serve the appropriate data. So in the API, it's like okay well, if it's authenticated, if it's not authenticated, give these response codes.

[00:03:41]
>> Scott Moss: Exactly.
>> Speaker 2: With this data. It's really just data in, data out and so you can do entire. You can write your entire test for your entire API and design it just from the data in data out and then you could do the code later.
>> Scott Moss: That's true, I never thought about it that way.

[00:03:57] Yeah that makes sense. The front end's like [LAUGH], there's so much. There's nothing to do with that at all. That's like one part of it, so yeah.
>> Speaker 2: Yeah I mean buttons, interactions.
>> Scott Moss: Right.
>> Speaker 2: Asynchronous data, all that stuff. But like especially with an API like a rest API.

[00:04:10]
>> Scott Moss: Right.
>> Speaker 2: Even a GraphQL API, it's data in, data out.
>> Scott Moss: Yep, and it's crazy because like, it's shifted. It used to be the fact that we're like, you would imagine like the back end just be like way more complicated to build features around stuff. And the front end was just like, this is for kids.

[00:04:26] It's a kiddie language, it's the front end. But now it's just like, actually the front end is so difficult to build stuff in now. And the back end is just like, this is so easy, this is so easy. I mean, sure, DevOps is a whole other thing. But like building the actual application on the back end is like, I find it way more satisfying than building code for the front end.

[00:04:42] Unless I build something that's like super snazzy on the front with animations or something, then that's awesome. But the dev process and writing the code and going through it is way more satisfying on a back end for me personally.