Accessing data that you’ve set in a previous callback can be a real challenge in Node.js. You want a clean crisp codebase that doesn’t rely on passing data around too much but the complexities of real-life code dictate a need to do so. This ends up turning some of the most beautiful codebases into a real mess; it’s chaos. In traditional threaded programming languages you get access to a thread-local storage of some kind where you can place data; in node you don’t really have anything within the core - globals and locally scoped variables - the beauty of JavaScript.
Any Node.js developer building HTTP based apps that live off the lifecycle of a request and response will have, at some point or another, added a variable to the req or res objects; you’ve hated yourself for it but it’s been the lesser of evils. Typically, at least for me as a micro-service API developer, I’ve wanted to give my requests IDs and pass those IDs to all my micro services so that I can log and track a request from the first inbound HTTP request, all the way out to my other services - tying up the data brilliantly but many other developers just want to store user information that they looked up at the beginning of the request; who am I kidding - we’re data hoarders and looking for any gain in our response times; we want to store anything that’s going to be used more than once. Historically this has been a huge pain in the rear.
Come find out how this becomes as simple as including a few modules and a couple of lines of javascript. Let’s get our app codebases back to beauty and restore order to the chaos.
About the talk
The idea of the talk is to show what you can do with the little known CLS module (others available) - I've been using it over the past months to increase the benefit of micro-service logging but there are many other benefits people can get out of it. The aim of the talk is to enable people to make their apps cleaner, tidier and more friendly to progress without the need of having to worry about passing variables along the callback/promise chain.
I'll be giving a longer version of this talk at Node Dublin at the end of May.
Proposal
Accessing data that you’ve set in a previous callback can be a real challenge in Node.js. You want a clean crisp codebase that doesn’t rely on passing data around too much but the complexities of real-life code dictate a need to do so. This ends up turning some of the most beautiful codebases into a real mess; it’s chaos. In traditional threaded programming languages you get access to a thread-local storage of some kind where you can place data; in node you don’t really have anything within the core - globals and locally scoped variables - the beauty of JavaScript.
Any Node.js developer building HTTP based apps that live off the lifecycle of a request and response will have, at some point or another, added a variable to the req or res objects; you’ve hated yourself for it but it’s been the lesser of evils. Typically, at least for me as a micro-service API developer, I’ve wanted to give my requests IDs and pass those IDs to all my micro services so that I can log and track a request from the first inbound HTTP request, all the way out to my other services - tying up the data brilliantly but many other developers just want to store user information that they looked up at the beginning of the request; who am I kidding - we’re data hoarders and looking for any gain in our response times; we want to store anything that’s going to be used more than once. Historically this has been a huge pain in the rear.
Come find out how this becomes as simple as including a few modules and a couple of lines of javascript. Let’s get our app codebases back to beauty and restore order to the chaos.
About the talk
The idea of the talk is to show what you can do with the little known CLS module (others available) - I've been using it over the past months to increase the benefit of micro-service logging but there are many other benefits people can get out of it. The aim of the talk is to enable people to make their apps cleaner, tidier and more friendly to progress without the need of having to worry about passing variables along the callback/promise chain.
I'll be giving a longer version of this talk at Node Dublin at the end of May.