watson
commented
5 years ago While this module can just as well be used in situations where the Node.js process isn't an HTTP server, let me just quickly answer your question in case it was always an HTTP server: Within a single request to the Node.js HTTP server the Node process might be performing several async operations:
- Making one or more database queries,
- Reading a file from the disk,
- Calling
process.nextTick - Making an external HTTP request to another service
- etc...
In all of these cases, whenever the async operation finishes, the JavaScript code executing on the stack has no knowledge of how the process got to that point. Every thing up until the callback was called is "lost". Notice how this can happen hundreds of times within the same HTTP request, and so there's no time to store a cookie in the users browser. So if you want to store a state between each of these async operations, you need to either:
- Pass the context along in a object to each function call
- Use a module such as this to restore the context before each callback is called
The former approach is a bit tedious, so many people like the latter approach better.
Forgive me for my questions if they seem obvious. I've recently discovered this package since we're using it in a project here on the job. From a high level, it seems that this package can set information in one module that can later be retrieved in a completely different module.
I'm sure this package is doing something special or addressing a particular use-case, what with all the talk about threading and Node processes, but the lightbulb isn't turning on for me. Why not just use cookies instead of this package? Cookies are accessible in every request made to the server. Just trying to understand the particular use-case of this package. Thanks in advance!