The Express.js app framework for Node.js is a pretty cool system that makes it easy to implement web apps and even REST API's. But the Express team doesn't give you any guidance on structuring the application code. They give you an API and it's up to you to decide how or even if you structure the model-view-controller paradigm or any other paradigm you wish to use.
An example of the problem is the question - Where do you define the routes? Where do you implement the routes?
The Express gives you the app.use
and app.get/post/etc
methods, but doesn't tell you where to put anything. It's up to you to organize everything to your own liking.
In my book, Node Web Development, I recommended this sort of organization
app.js
....
var homeController = require('./controllers/home');
var userController = require('./controllers/user');
....
app.get('/', homeController.index);
app.get('/login', userController.getLogin);
app.get('/logout', userController.logOUT);
app.get('/doStuff', userController.doStuff);
then in controllers/user.js
exports.getLogin = function(req, res) {
//logic...
});
exports.logout = function(req, res) {
//logic...
});
exports.doStuff = function(req, res) {
//logic...
});
There are other possible organizational paradigms to follow. Why did I choose this one? There's two advantages that I saw.
First - All the routes are in one place, in app.js
. That makes it easier to review the external interface of the web app, it's all in app.js
. Simple. Easy.
Second - It's easier to unit test the route functions. Just call the route functions with concocted request
and result
objects as any old function call. It's not necessary to construct a fake HTTP stack to unit test the router functions, you just call the function and inspect the result object. Easy. Simple. See Unit testing Express route handlers in isolation from everything, including Express