Middleware design pattern in Node.js: Connect

Question

This question extends that of What is Node.js' Connect, Express and "middleware"?

I'm going the route of learning Javascript -> Node.js -> Connect -> Express -> ... in order to learn about using a modern web development stack. I have a background in low-layer networking, so getting up and going with Node.js' net and http modules was easy. The general pattern of using a server to route requests to different handlers seemed natural and intuitive.

Moving to Connect, I'm afraid I don't understand the paradigm and the general flow of data of this "middleware". For example, if I create some middleware for use with Connect ala;

// example.js    
module.exports = function (opts) {
    // ...
    return function(req, res, next) {
        // ...
        next();
    };
};

and "use" it in Connect via

var example = require('./example');
// ...
var server = connect.createServer();
// ...
server.use(example(some_paramater));

I don't know when my middleware gets called. Additionally, if I'm use()'ing other middlware, can I be guaranteed on the order in which the middleware is called? Furthuremore, I'm under the assumption the function next() is used to call the next (again, how do I establish an ordering?) middleware; however, no parameters (req, res, next) are passed. Are these parameters passed implicitly somehow?

I'm guessing that the collection of middleware modules used are strung together, starting with the http callback -> hence a bunch of functionality added in the middle of the initial request callback and the server ending a response.

I'm trying to understand the middleware paradigm, and the flow of information/execution.

Stylish

Answer 1

The middleware is called as a chain of functions, with order based on middleware definition order(time) with matching routes (if applicable).
Taking in account that req and res objects are travelling through chain so you can reuse/improve/modify data in them along the chain.

There are two general use cases for middleware: generic and specific.

Generic is as you have defined in example above: app.use, it will apply to every single request. Each middleware have to call next() inside, if it wants to proceed to next middleware.

When you use app.get('/path', function(... this actual function is middleware as well, just inline defined. So it is sort of fully based on middlewares, and there is no endware :D

The chain order is based on definition order. So it is important to define middleware in sync manner or order-reliable async manner. Otherwise different order of middleware can break logic, when chain of middleware depends on each other.

Some middleware can be used to break the chain return next(new Error());. It is useful for example for validation or authentication middleware.
Another useful pattern of use for middleware is to process and parse request data, like cookies, or good example of such app.use(express.bodyParser());.

Portage

So if I had var A = require('./A'), B = require('./B'); app.use(A()); app.use(B()); then A would come before B, with A's next invoking B? Are the parameters then passed implicitly? Else how would B access req, res, ect? – Stylish

Exactly. req and res objects are travelling through and is same object in all the chain. So that way you might save some data in it, and then reuse it later in another middleware along the chain. That is exactly what happens with most of your data in req. For example by default POST body data is not parsed and express.bodyParser() middleware will parse it, and you have access to it later in chain. – Portage