Node.js and Express - is augmenting the request object a good idea?

Question

i am starting to learn Node.js and trying to understand the architecture of it combined with the micro-framework Express.

I see that Express uses Connect as a middleware. Connect augments the request and response objects with all kinds of stuff in a chain of functions, and it provides an API so you can add custom middleware. I guess this augmenting is a way to keep things simple and flexible in the handlers/controllers, instead of having a variable number of parameters and parameter types. Here is an example of a simple GET handler:

app.get('/', function (req, res) {
    res.render('index', { title: 'Hey', message: 'Hello there!'});
})

In tutorials from Node.js experts i have seen stuff like augmenting the request object with a MongoDB collection. In a blog from Azat Mardan i have seen this code :

var db = mongoskin.db('mongodb://@localhost:27017/test', {safe:true})

app.param('collectionName', function(req, res, next, collectionName){
   req.collection = db.collection(collectionName)
   return next()
})

The approach above is using the 'collectionName' parameter in the route name as a conditional to control the augmentation of the request. However, i have seen uglier code where the database middleware is attached on EVERY request that goes through Node.js without this conditional approach.

Looking at standard software principles like single responsibility principle, separation of concerns and testability why is it a good idea to extend the request with a MongoDB collection object and dozens of other objects? isn't the request and response object bloated with functionality this way and has unpredictable state and behavior? Where does this pattern come from and what are the pros and cons and alternatives?

Answer 1

This is fine. IMHO the very purpose of the request object is as a container to pass things down the stack for other handlers to use. It is far cleaner than looking for some agreed-upon-named global holder.

You could argue that it should be mostly empty, and then have the "official" request and response functionality on some property of the request/response objects, so it is cleaner, but I think the benefits are minimal.

Matter of fact, just about every middleware I have seen, including looking at the express source code and ones I have authored, uses request for exactly this sort of "container to pass properties and functionalities down the handler stack".