Stop the req bloat! Learn how to attach meta-data and information across an asynchronous call-chain in Node.js the smart way, without the clutter, collisions, or even middleware.
collection of express/connect middleware, an async.waterfall flow, or something as simple as a series of asynchronous functions and callbacks. a lightning talk by @FredKSchott Annotation Annotation slides added for context ⬡
But what can we do with it? next() doesn’t take a user argument, and even if it did you wouldn’t want to pass it through each and every function. At the bottom of the chain -- our final middleware -- we want to get that user. Is there a simple way to do this? Annotation ⬡ a lightning talk by @FredKSchott
is to leverage the request object that’s passed from middleware-to-middleware. A value or method attached in the first middleware will still exist in the last. Problem Solved! …right? Annotation ⬡ a lightning talk by @FredKSchott
= req.translate; var sdkClient = req.sdk; var traceID = req.traceID; var logger = req.logger; // This is the worst. if( req.featureflip['foo'] { req.isThisRediculous = true; } res.send(200, 'Hello ' + user.name); } // I Hate you.
cluttered your request object can get if you’re not careful. And eventually you’ll find yourself attaching things that don’t belong, things that aren’t really properties of the request. Annotation ⬡ a lightning talk by @FredKSchott
logging and tracing tools for New Relic. He needed a way to attach meta-data along the call- chain that could be accessed when it was time to log. Annotation ⬡ a lightning talk by @FredKSchott
do this… and they didn’t do it well. They were originally intended for error handling, and came with a significant performance hit just by including them in your project. Have fun explaining that in your ReadMe… Annotation ⬡ a lightning talk by @FredKSchott
it required access to Node that wasn’t available yet. However, the lead contributors were wary to add another core module unnecessarily. Instead, they accepted the improvements to Node.js that would allow CLS to exist in user-land. These improvements became the AsyncListener API. Annotation ⬡ a lightning talk by @FredKSchott
namespace in the first middleware, which persists all the way down the call-chain. Data stored within that namespace is unique to that request and namespace. Multiple namespaces can exist for each request, so there’s no limit to how many modules can use CLS without conflict. Namespace are tied to the call-chain