API Design in Node.js, v3 Refactoring CRUD Routes with Models

Transcript from the "Refactoring CRUD Routes with Models" Lesson

[00:00:00]
>> Scott Moss: But yeah so ultimately, controllers are gonna implement the logic that interacts with our database models, right. So we created those models. Where do we use them? We use them in the controllers. So, that's basically how they're gonna work. The sweet thing about REST and how Express gives us tools for route matching and verbs.

[00:00:19] And then how Mongo kinda ties into a lot of this stuff too, is that we can actually generalize our controllers to work for many different models. If you go look at the routes that we had,
>> Scott Moss: Our router, already have it right here. So let me just get rid of this controller.

[00:00:41]
>> Scott Moss: If we go look at these routes here.
>> Scott Moss: We kind of generalized these to just have two routes, so it's / and then /id. And they just have different verb combinations, so we generalize that. And that's gonna be the same no matter which resource we're on, right.

[00:00:57] If I go to list router, it's exactly the same thing. If I go to the user model, this one's going to be different. Because user has different permissions and stuff, but there's some similarities here. The reason user is different is because you sign up, signing up and creating a new item are two different things.

[00:01:16] Signing up as an user is not as simple as like doing CRUD user, like creating a user. Normally when you create a user, I don't create a user for somebody else. They sign themselves up, so they're not a user yet. So I already perform CRUD, so that's why it's a little special with users and stuff.

[00:01:31] But for most resource based stuff in our database, it's mostly the same thing. So because of that, that similarity we can actually generalize our controllers too. They're all doing the same thing. For instance, if a list has a controller to get one list by an ID, then that logic would be exactly the same as an item controller getting one item by an ID.

[00:01:54] The only difference is at the model. One's a list model, the other one's an item model. But because Mongoose makes all the models exactly the same, as far as the methods you can use on them. Then we can just generalize the controllers and just create one controller for every single CRUD action then just pass in the model and then we are done.

[00:02:13] Technically that's your work if you follow REST exactly to T. Where that gets crazy is when you got to do special things like, we got to remove the password from the user or we had to populate this field. But then you're not doing REST, that's where it gets blurry.

[00:02:27] So for ultimate REST, yeah, we can generalize the controllers to work for everything. And that's actually what we're gonna be doing next. Anybody not understand me when I said what I just said, generalize our controllers? I think I was talking too fast. But basically, what I was saying is, instead of writing a controller for every single route, for every single resource.

[00:02:49] We'll just write one controller for getOne, one controller for createOne, one controller for updateOne, one controller for removeOne, and one controller for getMany. And then we'll pass a model to that controller and it'll just do the same code for every single model. Cuz it's very generic, it's very general, does the same thing just on a different model.

[00:03:08] Doesn't need to know about fields, doesn't need to know about schemas. It just does the same thing on every single model. And that's exactly how Ruby on Rails would have generated routes for you if you were using it back when they were coming out with the res stuff.