✅ Access to child logger in beforeRouting

[williamgcampbell]

It looks like the logging middleware is the first thing run in createServer, but the request logger is tucked away in response.locals under a private metadata symbol. I could reverse engineer this and just pull the logger out using that same metadata symbol but I think there's a good case to be made for purposefully exposing that logger for other middlewares run in beforeRouting.

[RobinTail]

it's already available for you, @williamgcampbell

I could reverse engineer

could you please explain what exactly you do want?

[williamgcampbell]

Ah, when I say request logger I mean the child logger for that request. The logger that's pushed into the beforeRouting function is the rootLogger, which makes sense because it's all we have at the time that we are initializing the server.

I need access to the child logger that's created in the logger middleware at the time of the request. The reason this is important to me is because I have similar motivations as #1650. I'd like to be able to, very early on in the middleware chain, wrap the next express function in a local storage with an applicable logger. I have other libraries that decorate the logger with a trace context, so using this logger is important for stitching applicable logs together.

[RobinTail]

can only suggest you placing all that inside config.childLoggerProvider, @williamgcampbell

[williamgcampbell]

The only place this can be done is somewhere that I have access to both the logger and the Express next function. Unfortunately childLoggerProvider doesn't expose next, and I don't actually think it should.

What I was hoping for was an on-road solution for express-zod-api to pass data using response.locals with a typed interface, rather than hiding it behind a private lookup key.

[RobinTail]

I'll take a look what I could do for you, @williamgcampbell

[RobinTail]

FYI, there is a reason behind the decision to place the child logger under a proprietary symbol of response.locals.
https://expressjs.com/en/4x/api.html#res.locals
I did it because the primary purpose of locals is to be used by template rendering engines.
Therefore it's an end-user namespace that I tried to avoid interfering with such way.
I also decided not to go with assigning additional props to request, but still to use the existing typed storage.

[RobinTail]

Would this work for you, @williamgcampbell ?

[williamgcampbell]

It does! I can't think of any other metadata we might need but it could be more extensible as a typed object.

// ResponseMetadata holds metadata specific to the current request. 
interface ResponseMetadata {
  logger: ActualLogger;
}

types BeforeRouting = (params: {
  app: IRouter;
  logger: ActualLogger;
  getMetadata: (response: Response) => ResponseMetadata;
}) => void | Promise<void>

[RobinTail]

I'm thinking on making it more intuitive by accepting request argument...

[RobinTail]

yeah, that seem to be working.

[RobinTail]

the final naming and the interface will be getChildLogger( request )
I like that it for the clarity.

[RobinTail]

Dear @williamgcampbell ,

could you please try the recently released version v20.8.0-beta.1 and let me know if it works fine.

Here is the usage example for you:

import { createConfig } from "express-zod-api";
import { randomUUID } from "node:crypto";

const config = createConfig({
  logger: { level: "debug" },
  childLoggerProvider: ({ parent }) =>
    parent.child({ requestId: randomUUID() }),
  server: {
    listen: 80,
    beforeRouting: ({ app, logger, getChildLogger }) => {
      logger.info("This is root logger");
      app.use((req, res, next) => {
        getChildLogger(req).info("This is a child logger");
        next();
      });
    },
  },
});

[williamgcampbell]

yep, this works!