API Design in Node.js (using Express & Mongo) Application Organization
This course has been updated! We now recommend you take the API Design in Node.js, v4 course.
Transcript from the "Application Organization" Lesson
>> Speaker 1: Now we're gonna talk about organization and config. So this is where we're actually gonna start building the API and doing stuff. And it's gonna get kinda crazy. we're gonna jump a couple steps, and we're gonna talk about how to really get the API going. So, organization and config.
[00:00:22] Our API will consist of many different components.
>> Speaker 1: Typo. To support the API authentication, static serving, etc. So when you hear me say the word API, I'm not just talking the rest in points. This is actually really gonna be like a web server that has an API aspect of it.
[00:00:40] So we'll be serving a site or, actually, maybe I won't. Maybe I won't serve this site. But it definitely will be doing authentication. So we'll have authentication, authorization, identification and then the API. But what actually makes up the API portion of the server, right? So, if we look at our code, we kinda figure that out already.
[00:01:04] We know that in our server js, we have middleware, we have these routes. We have these routers, and then we have these crud operations here. All right. We can break that down to different components of our API.
>> Speaker 1: So the API is really just a collection of resources with models to define how the resources look.
[00:01:32] So, and then we have controllers to access those resources and routes to let the controllers know how, all these typos. It's really hard to read. Know how to run and expose our API.
>> Speaker 2: We'll have to have an editor go through-
>> Speaker 1: Yeah.
>> Speaker 2: With your whole-
>> Speaker 1: Yeah [LAUGH]
>> Speaker 2: Yeah.
>> Speaker 1: That old thing again. That would be great.
>> Speaker 2: [LAUGH] Before we launch the course.
>> Speaker 1: Yeah, we should totally do that. [LAUGH] It's like at least 100 typos in here, so.
>> Speaker 2: [LAUGH] At least 100.
>> Speaker 1: Yeah. But, yeah so, resources, which are like the models.
[00:02:06] So our lions our tigers, those are resources, those are our models. And then we have controllers that define, that gives us access to the models. Those are the things that's gonna interact with the models. And then the routes are the things that are gonna call the controllers. So they're, the controllers are the call backs to the routes.
[00:02:23] And the controllers themselves interact with the models. So we have our routes here, that our client's talking to. We have our models over here. And then right in the middle is our controllers. Our controllers are like, okay, I'm gonna wait for the router to tell me to do something, then I'm gonna go talk to the model and come back and give it back to the client.
[00:02:39] So the controller's sitting right in the middle. Does that make sense?
>> Speaker 1: We've been doing that this whole time. So
>> Speaker 1: it's nothing different. So we have our servers. I'm sorry. Here's our routes. Boom, go to lions, go to lion router, great. And then we set up these routes here.
[00:02:58] So, here are our routes.
>> Speaker 1: This callback function right here, this is like our controller. That's the controller is this function, and what's happening in the function. And then as far as the models, it's just this lions array right here.
>> Speaker 1: So, we've been doing it the whole time.
[00:03:14] Our controllers are the thing that's doing crud operations on the model. So right here, we're adding to the model. We're deleting. These are all our controllers right here that's interacting with the lions model. That's being, that's reporting back to the routes of the request.
>> Speaker 1: So we have our routes, our controllers, our models.
>> Speaker 1: So a model is just a blueprint of what our resource may look like. So, again, yesterday we were talking about that, right? It's just a blueprint of what our resource is gonna look like. That's what a model is. Or somewhat.
>> Speaker 1: So just like the blueprints we made in the JSON above, the controllers are the glue between the routes and the models.
[00:04:05] And like I said, we've been using controllers and routes the whole time. So MVC is a classical organization pattern, especially for the servers. We're gonna take a service oriented approach instead. So, we're not gonna organize our application in traditional MVC pattern, where it would be something, in our server we have a folder for all our controllers, and a folder for our routes, or a file for our routes, and they're like a folder with all our models.
[00:04:31] We're not gonna take that approach. The approach we're gonna take is a more of a service oriented approach instead. So instead of grouping our code together by type, like all controllers go here, all models go here, all routes go here, we're gonna group them together by feature, by functionality.
[00:04:45] So, it's like everything to do with a lion goes here, whether that's a controller, a test, a route, a model. Everything about the lion goes here. Everything about the tiger goes here. All right? So we'll bundle the resources, routes, controllers, model into one directory. And tests, too. So that looks like this.
[00:05:06] So in our API folder, we'll have for instance, a todos/ resource. It has its own model, its own controller and its own routes.
>> Speaker 1: So that's pretty much it as far as organization. And then we have other things like a config folder where we store config stuff. Maybe a utilities folder where we store utility functions to help us out.
[00:05:34] Maybe authentication folder to store authentication stuff. But the important thing is just how we organize the models, the API.