Discussion on: Tracing requests in Node.js?

[Henry Williams]

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]

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]

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]

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]

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.

[Mihail Malo]

It's just the most obvious pattern for me. I haven't made large HTTP APIs in nodejs, but I have done something similar.

It just seems logical:
Q1: I need to access the context, the shape of which is technology-specific and won't change any time soon in a function I call from the handler that has access to the context.
A1: Well, just pass it in, yo!

Q2: I want to have type-annotated functions that make use of the context in my files, without bringing any annotation into my files.
A2: Import the CODE of the functions explicitly, to reference the annotated file, and pass them the "untyped" but well known context object.

[Henry Williams]

Makes sense. Thanks again for sharing the knowledge!

[Sathish]

Hi Michal that weakmap approach. Now instead of passing logger needed to pass the request to every function. How is that different from Henry class solution.. am I misunderstood something. ? Thanks for your help

[Mihail Malo]

@sathishkumarsoundharajan When it comes in as a constructor parameter or method parameter, to have it be typed in your editor/IDE, you have to annotate it in place.
@henryjw posed a particular problem, where they didn't want type annotations inside the handler method files. In order to still have types available, the logger must be imported instead of injected. So, we import a function that provides the logger.
How does it tie the logger to the current context? Well, why not use the request.
So, we import the logger "factory", give it the untyped "req" object, and get back a strongly typed (in terms of editor autocompletion) logger object.
Can do it like this if we don't want to have a special middleware createing the logger first:

// logger.js
const map = new WeakMap

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

So, if your whole project is in TypeScript or something, it isn't a big advantage.
And if you don't care about typings, it isn't a big advantage.
But it solves the unique specific problem posed in the post.

It's still less coupling/boilerplate than providing specifically the logger as a service constructor argument or method argument. All mentions of "logger" will disappear from the routing glue code (except where you want to log for routing reasons).