DEV Community

Tracing requests in Node.js?

Henry Williams on January 21, 2019

TLDR; How can I maintain request context without having to pass the logger (or requestId) around and without using cls-hooked? If there's no bett...

Read full post

Mihail Malo • Feb 17 '19

I think you aren't getting answers because your situation isn't clear at all.
I am going to assume this is Express?

What do you mean when you say "logger", what context does it have?
How did that context get into it?

What do you mean by "type information getting lost"?
How was type information previously available, until it got lost?

Henry Williams • Feb 17 '19

Thanks for the response. Basically, the problem I'm trying to solve is having some context/info about the request throughout its lifetime anywhere in the app. For instance, being able to retrieve the request ID for the request in context from any module.

This is tricky in Javascript because the app runs on a single thread, as opposed to other languages and runtimes that spin up a new thread for each request served. The solution that is commonly recommended is using cls-hooked, but it's not very reliable since the "thread" context is easily lost.

Mihail Malo • Feb 17 '19

Well if the "logger" is populated with something specific to the req, it doesn't seem like a bad idea to have it on the req object.

I'd even go so far as to say constructing the object didn't really improve much.
I guess one benefit could be that you don't have to know if this particular function might make use of the logger. But that could be easier achieved by passing it to all functions of the service, since most probably will, and one might want to, someday, without changing the call sites.

Now, what was the "type information" you were talking about?
Is your project using TypeScript?

Henry Williams • Feb 17 '19

I like that solution of passing it by default since it'll most likely be needed. I guess it would be a matter of making it a standard coding practice to always pass the logger.

As for the typing, since the logger is just passed around, there's no typing information associated with it (I'm using plain javascript). JS docs would solve this problem by specifying the type of the logger parameter on each function, but I'm looking for a solution with less development overhead.

Mihail Malo • Feb 17 '19 • Edited

Instead of annotating every function, you could have a context object you pass around (heck, it can even be the req) which you pass to your logger "factory"

// logger.js
const map = new WeakMap

export const create = req => {
  const logger = new Logger(req.something, req.somethingElse)
  map.set(req, logger)
  return logger
}

export const get = req => {
  const logger = map.get(req)
  if (!logger) throw new Error('CATASTROPHE: no logger on req')
  return logger
}

Then you can annotate just the get function, and the return value of require('./logger').get(req) will provide type suggestions inside your unannotated plain js files.

There are many options, for example instead of needlessly constructing the logger, if it will only rarely end up being used, you could attach the data you need (or nothing at all, just extract it from the normal req when needed) and make use of it by passing the object at the callsite instead of geting the logger.

Henry Williams • Feb 18 '19

I definitely like this solution of passing the context instead of the the logger. Thanks a lot for the suggestions!

By the way, is this also a solution you've had to go with for log tracing in Node? Or have you never had this issue? Just curious to know if I'm approaching this problem incorrectly.

Fernando Calvo • Feb 21 '20 • Edited

Hi! pretty late but maybe this helps others, what I usually try is to inject the models or the services in the request, so from your router code you can do something like

app.get(
    '/api/v1/customer/:id',
    async (req, res, next) => {
        const id = req.params.id
        const customer = req.context.customerService.get(id)
        /// ... process and return response
    }
)

You should create the customerService in a previous middleware and inject it to the context, so you can access to it from the context, and the service can access to the context as well.

I wrote a blog post about it here dev.to/fernandocalsa/sharing-the-c...

Marcel Chastain • Aug 5 '20

Late to the discussion, but as of Aug 2020 there's an excellent option.
cls-rtracer v2 uses the native AsyncLocalStorage API, which should be more robust than cls-hooked.

If you still run into issues losing your thread context, there was also mention that a potential workaround was to re-order your middleware.

Good luck!

Henry Williams • Jan 29 '19

Anyone? :(

Sathish • Mar 7 '19

Hey Henry I am also facing the same exact problem right now. Also decided to use the class based approach. Cls-hooked not only have problems on losing context and also have performance bottle necks.. I have been searching around for a cleaner solution like this. Did u come up with someone different ??