nanostack

Small middleware stack library. Analogous to co but without relying on fancy language features. Weighs ~0.4kb gzipped.

Usage

var nanostack = require('nanostack')
var stack = nanostack()

stack.push(function timeElapsed (ctx, next) {
  var start = Date.now()

  next(null, function (err, ctx, next) {
    if (err) return next(err)
    var now = Date.now()
    var elapsed = start - now
    console.log('time elapsed: ' + elapsed + 'ms')
    next()
  })
})

var ctx = {}
stack.walk(ctx, function (err, data, next) {
  if (err) throw err
})

How does this work?

A stack is a "last-in, first-out" type structure. The last thing that's added is also the first thing that's taken off when you "unwind the stack".

In nanostack we push middleware onto the stack. This means that middleware is first executed upwards (e.g. next function in sequence) until next() is called without a callback. When that happens the stack starts to unwind, and middleware is executed downwards. You can think of the execution order like this:

  Nanostack
1.          7.  Middleware 1
==============
2.          6.  Middleware 2
==============
3.          5.  Middleware 3
==============
      4.        Middleware 4

Sequence: middleware 1, middleware 2, middleware 3
          middleware 4, middleware 3, middleware 2
          middleware 1

A keyd thing to note here is that any part of middleware can cause the stack to unwind. This is done by not passing a callback into the next() function. This is for example useful to handle create generic error handlers for the whole stack of middleware.

API

stack = nanostack

Create a new nanostack instance.

stack.push(cb(ctx, next))

Push a new handler onto the middleware stack.

stack.walk(ctx, next)

Call the functions on the middleware stack. Takes an initial context object and a callback.

next([err], [value], [handler])

Call the next function in the stack. If handler is not passed (e.g. last argument is not a function) the stack unwinds, calling all previous handler functions in reverse order (e.g. as a stack).

FAQ

Why did you write this?

I realized that most frontend and backend plugin systems / middleware is often best expressed as a stack that can execute some code at the start, handing off control to a function up the stack and then execute some more code when it regains control (before handing control off again down the stack).

co figured this out a while ago, but relying on newer language features prevented it from being generally applicable (for me). This package takes the same ideas and allows them to run in more environments.

When shouldn't I use this?

This package is probably best left for frameworks to consume / when doing more complex-ish architecture things. Generally the last handler on the stack would be a message bus / router that enables multiple handlers to resolve. If you're building something simple that might be all you need actually. Or if you want to get fancy you might want to consider using a package that consumes this one and exposes a neato pattern on top.

Similar Packages

• tj/co

License

MIT