Constantly Losing Stuff: continuation local storage in Node
summary
Continuation Local Storage implements per-request globals for Node by creating process-wide namespaces and running code inside them, backed by an async-listener API that monkey-patches core async ops. The module is roughly 150 lines of JS while the listener is ~450 lines, handles transactions in production (used by New Relic in production), but needs explicit namespace.bind or emitter binding for connection pools, streams and many promise libraries; CPU cost spikes in tight loops (tests showed ~800x) but is negligible with I/O.
AI-written summary · about
chapters (12)
- 0:00Introduction and speaker intro
- 1:52Thread local vs continuation passing
- 3:38Problems with request state handling
- 6:25Introducing continuation local storage
- 8:56How continuation local storage works
- 12:04CLS API and usage basics
- 13:07Practical use cases for CLS
- 14:50Handling edge cases with CLS
- 17:16Performance and trade-offs
- 18:45Who uses continuation local storage
- 19:47Alternatives in browser and Node
- 22:33Future of CLS and next steps
