In the previous post I provided a short introduction to Express, a web development framework built on top of connect that is heavily inspired by Sinatra. For this post we’ll dive into a couple of styles for dealing with routes in Express.
Express simply uses HTTP verbs for its routing API.
Well, that’s pretty much all that you need to get started. The routes that we specified here are treated as plain old regular expressions. Note that in order to make the put and delete routes work, we have to add a hidden field to the view.
But the thing that I personally struggled with the most was finding out a decent way to divide up these routes into separate modules without too much of a hassle. Most sample and demo applications out there that use Express usually have all their routes specified in a single app.js file. This is something that I don’t like very much as this can become unmaintainable faster that you might think. Roughly 2000 years ago, there was this great emperor (and many after him) who valued the principle of Divide and Conquer. In order to create maintainable applications, being able to divide up these routes is quite essential. There are several ways to do this.
Express Resource
This library enables us provide resourceful routing. As usual, express-resource can be installed using npm by using the following command:
npm install express-resource
Using express-resource, we can create controller modules and use them from our main module. The following snippet shows how a simple controller looks like:
Now in the main module (app.js) we just have to add the following code:
That’s it! Now all these routes are hooked up and ready to use. Express-resource has a few other neat features as well. Check out this episode from Node Tuts to learn more.
Although this seems like a good solution to divide up routes into controller modules, somehow it doesn’t resonate with me. All routes for a particular resource need to exist in the same module which still feels a bit unwieldy to me. I want to have an even more granular approach.
Super-duper Require
What I like to do is to separate routes based on their context:
- runs/index.js ( index route )
- runs/new.js ( new and create routes )
- runs/show.js ( show route )
- runs/edit.js ( edit and update routes )
- runs/delete.js ( delete route )
Wouldn’t it be cool if we could just “require” the runs directory and hook up all routes exported by all the modules that exist in this directory? Well, meet super_duper_require! While still using express-resource, we can now add all these routes like so:
This is how the super_duper_require function looks like:
We just use the magnificent underscore.js library here to hook things up. This is just one of the fancy ways to solve the granularity problem. If we don’t want to use the express-resource library, we can always accomplish the same thing by going “plain old school” style.
Plain Old School
This is how I currently set up routing with Express. We no longer need the express-resource library for setting up our routes, but we can still use the same granularity as shown earlier. We also need underscore.js again, just as in the previous example, in order to stitch things together.
// Index
app.get('/runs', function(request, response) { });
// New run
app.get('/runs/new', function(request, response) { });
// Create a new run
app.post('/runs', function(request, response) { });
// Show run
app.get('/runs/:id', function(request, response) { });
// Edit run
app.get('/runs/:id/edit', function(request, response) { });
// Update run
app.put('/runs/:id', function(request, response) { });
// Delete run
app.delete('/runs/:id', function(request, response) { });Up until now I’m pretty happy with this approach. I would love to hear how others divide up their routes into several modules. So please let me know if there are other awesomely cool ways to deal with this. In the mean time, I hope this helps.
Until next time.
