Mounting Routes with use Middleware

[00:00:00]
>> Speaker 1: All right, now let's mount these onto our server, so I keep talking about that What does that actually mean and why haven't I added the full routes to these things Basically, the way that we want to do this is we can say an app, we can say, "Hey, for this route." There's another method here that has nothing to do with HTTP verbs but a method associated with AI

[00:00:00]
The `.us` just means, "Hey, for this route." No matter the verb, it doesn't care about the specific method—just this route with no verb, right Where it's like all of these are like a method/verb combination, "Hey, for this method and this route, do this," whereas `.us` is just for every single verb on this route

[00:00:00]
What we're going to do here is we're going to say, "Hey, if anybody ever goes to `/api/auth`," what we want to do is show them the auth router So we need to import that We'll say, import `authRoutes` from `./routes/auth.js` You have to do the file extensions if you've written Node, and when you switch over to using ES modules in Node, you have to do the file extensions

[00:00:00]
Using TypeScript doesn't change that If you don't put the file extensions, it will not import it We'll get all the routes, import the other ones while we're up here We've got the `userRoutes`, and then we have the `habitRoutes` I have another one here called tags, but I'm not going to add that because it's mostly the same as everything else

[00:00:00]
I'll leave it as extra credit for you to work on—it won't affect what we're doing here today It's just something I was going to do that seemed repetitive So, `app.use`, if anybody goes to anything `/api/auth`, I immediately want to load up the auth routes

[00:00:00]
Now when I load the auth routes, what's going to happen is we've got `/api/auth` The auth routes get loaded up, and then it's `/register` That means if anybody goes to `/api/auth/register` and does a POST request, then this will run

[00:00:00]
These routes are mounted at this path, and this is a good way of doing this because now this router doesn't need to know where it needs to be registered I can just change this here if I ever need to, and I never have to change anything in this code

[00:00:00]
It's decoupled I'll do the same thing for the other routes Users, we'll say `userRouter`, and then we have habits—I should rename all these to be consistent, sorry about that `habitRoutes`, there we go Now we have all of those mounted at subroutes, so let's try to test them out and see if we broke anything

[00:00:00]
Everything reloaded, nothing's broken Let's make sure our health check still works Health check GET request should still send me back a button If I go to `/api/habits` as a GET request, I should see a JSON message that says "message: habits" because that's `/api/habits`, and slash just means the route I'm on

[00:00:00]
Let's run that in Postman, and boom, I see "message: habits" Now I'll check users—`/api/users`—and I see the users route If I do a POST to `/auth/register`, I should see "User signed up" Even though we're using specific CRUD or RESTful methods like POST, because we're not doing anything in the response body, it doesn't have anywhere to write to

[00:00:00]
Why aren't we getting an error for not fully implementing the intended verb The reason is that REST is an agreement among developers, and no framework enforces that, including Express Express only cares that you send back a response or throw an error

[00:00:00]
It doesn't know or care about the intent of POST or what it's supposed to do The HTTP spec is codified, but the REST spec is just an agreement Express implements HTTP verbs but makes no opinions about what you do in the handler That business logic is something you as an engineer would implement and enforce through code reviews and standards.