9 thoughts
last posted Aug. 30, 2014, 8:41 p.m.

8 earlier thoughts


This week I had to add caching to a specific HTTP endpoint. The endpoint is implemented in Express/Node.js, and unfortunately has caching semantics that mean a general purpose cache (i.e., Varnish) isn't appropriate. If I were still working in Django, I'd have either decorated the function, or written a piece of middleware to handle the caching. So my first exploration was in that direction.

I read the Express docs, and then I read the Express code. I'm not in love with NPM's dependency resolution model, but I do like that all of your dependencies are just in a sub-directory for easy perusal: no site-packages, dist-packages, virtualenv, etc to explain.

I learned that to do the sort of wrapping that's so natural in Django with Express middleware meant overwriting a bunch of methods on response to catch the output as it streams by. If you just override end, you're probably too late.

For an example, check out the compress middleware. It makes for some difficult reading.

I'm more aware today that there are layers to learning: there are facts, and there are implications. I knew the fact that Express was good for streaming responses, but hadn't considered what the implications of that were on how I'd write collaborating code.