Sometimes we want to define specific middleware for certain routes to use, and one of the easiest ways to do that is by using a router. We'll look at how to do that in this lesson.
1.Introduction3 lessons, 20:17
2.Building a Web App6 lessons, 1:01:23
3.Middleware and Routers2 lessons, 16:36
4.Conclusion1 lesson, 01:31
In the previous lesson, we wrote our own middleware for logging the requests to our application. And while it was very simple, it does work. I mean, we can complain that we're not logging enough information, but I think it's fine for what we intend to use it for. But let's say that now we want to change our application so that we are only logging the guitar requests. We don't care about the home or anything else, but we want to see who's accessing, or see how often our guitar URLs are being accessed. And we can do that, but in order to do so we need to create a router. Now, there is a built-in router for every express application. In fact, every time that we have used the app object to set up a route using the get, the post, the put, or the delete methods, we have used that built-in router that's called basic routing. So what we want to do is create a separate router. One that's going to have its own middleware, so that we can specify that our guitars router is going to have the logger middleware. Our application won't, so let's go ahead and comment that out, because we only want to log the guitar requests. So instead of guitar routes, we're going to need to make a few changes, not a whole lot. The first is, we need to pull in Express. Because in order to create a router, we have to have access to Express. So let's do that. And then after our guitars repository, let's go ahead and create that router. To do so we say, express.Router, with a capital R, and we now have a router. Now because we are going to perform the logging here, we also need to pull in the logger as well, so we will require that. That is in a directory that is above this one, so we will need to make sure that our path is correct. And then we will set up the logger middleware for this router. And we do that with the use method. So we will pass in logger. There we go, we have just set up the logger middleware for this router. And so you can start to see that there is some similarity between using the router and using the app object. In fact, what we're going to do then is we're going to take out the routes that we've defined inside of this function that we've exported. Because we no longer need to do that. We have the object that we need to set up those routes, which is our router. So we're going to use that to set up the /guitars route. Then we're going to use that to setup this /guitars/id route, and there we go. Now as far as the export is concerned, we can do this in a couple of different ways. The first would be to go ahead and use the infrastructure that we have built, and we can say app.use, and then router. So in this case, our router is then a part of the middleware. But that's exactly what a router is, it's just nothing more than specialized middleware. So this is one option. The other option would be to export the router itself, so that we could say module.exports = router. And then inside of routes, we could then do something like this, app.use and then guitarRoutes. Either way we would end up with the same results. Since the first way of just passing in the app object is what we have, let's stick with that. Because that's mean that's less files that we have to touch and modify. So inside of our guitar routes, we are going to use the router, and that's just going to make everything work. So if we go and look at our application, let's make a request for guitars. Now, if we look at the console, we are going to see that that was indeed logged, we see it right there. And if we make a request for anyone of the detail pages, we see that that still works. And once again, that was logged to the console. But if we make a request for home or contact, we can see that those work but we didn't see them logged. So we now have the results that we wanted. We created a router specifically for the guitars. We assigned it specific middleware that is only going to execute for the routes on that router, and we're good to go. But let's say that, okay, we want to change our URL scheme, because guitars is rather generic. We decided that we want to have a guitars that's going to list kind of like an encyclopedia of guitars. And then we're going to have an endpoint that's just myguitars, which is what the current guitars end point is for. So let's say that we wanted to change this to myguitars. Well, we would have to do that here, and we would have to do that there. It's not that big of a deal, really, but let's back out of those changes. What if we could specify a prefix? So that whenever we set up the router as middleware for our application, we could set up a prefix so that this router is for all of the requests that begin with myguitars, just like that. And then all of the routes that we define then are going to be relative to this prefix. So that our first route for displaying the index of myguitars is now just a slash because that is the root of myguitars. The same would be true for the id route. We can get rid of guitars so that then, we just have the id, which is then relative to my guitars. So if we go to the browser, of course, ourguitars isn't going to work anymore because we changed it. But if we change it to myguitars, well then, that works. If then we decide that okay, that was a bad decision, let's go back and change it to guitars, then everything's fine. We only make one change and everything still works as it did before. So when you want to create a router that is isolated from the main applications router, you can just create your own. You can assign whatever middleware that you want to that router. You can also define the routes for that router, and you can use it as middleware for your application. It gives you so much more flexibility.