is it possible to override the logger in a middleware?

[elee1766]

hi, i was wondering if it was possible to replace the logger for downstream handlers with a child logger in the middleware.

i'm trying to do this because i'm trying to create a child logger based off request headers and have the downstream endpoints use it.

[RobinTail]

Sure, @elee1766

If you're using winston, here is how you create a child logger:
https://github.com/winstonjs/winston?tab=readme-ov-file#creating-child-loggers

There are similar methods in pino and other compatible loggers.

Here is what you should do:

• Create a child logger within your middleware,
• Put that child logger into the returns of the middleware,
• Take it from the options parameter of your Endpoint's handler (instead of logger parameter).

There was also a dedicated discussion on custom loggers and child loggers too: #1311
And here is the documentation article on that topic: https://github.com/RobinTail/express-zod-api?tab=readme-ov-file#customizing-logger

I hope it helps.

[RobinTail]

Worth to mention as well, that the child logger placed in the options does not reach a ResultHandler.

[RobinTail]

There was another discussion about that: #718

[RobinTail]

I think I could actually make such a feature for configuring a "child logger producer", that will make a new instance for each request and downstream it to the very end (ResultHandler)

[RobinTail]

Or maybe I could let options to go to the ResultHandler as well. That might be the best and straightforward way without any magic.

[elee1766]

Sure, @elee1766

If you're using winston, here is how you create a child logger:
https://github.com/winstonjs/winston?tab=readme-ov-file#creating-child-loggers

There are similar methods in pino and other compatible loggers.

Here is what you should do:

• Create a child logger within your middleware,
• Put that child logger into the returns of the middleware,
• Take it from the options parameter of your Endpoint's handler (instead of logger parameter).

There was also a dedicated discussion on custom loggers and child loggers too: #1311
And here is the documentation article on that topic: https://github.com/RobinTail/express-zod-api?tab=readme-ov-file#customizing-logger

I hope it helps.

I hoped I would be able to replace the actual logger object instead of passing the new one through options. what you describe is what I'm currently doing with pino.

I guess I could put the logger type into global type declaration, which would mean a little less repeated code (options:{logger} instead of just logger).

I'm using the headers in my logger in order to pass the keys for distributed tracing down to some shared singleton services. basically i am using it like go context.Context, where i can pass information i want from the parent routing context to the service, separate from the entire http routing context

maybe I am solving this problem the wrong way though. I'm not sure how else though to pass bits of the route context to objects not within the framework

[elee1766]

I think I could actually make such a feature for configuring a "child logger producer", that will make a new instance for each request and downstream it to the very end (ResultHandler)

perhaps i need to read the code some more - does the middleware abstraction for express-zod-api not include a parallel to "next"-style middleware?

to me it would make a lot of sense if upstream middleware could call the downstream handler and therefore provide a child logger, (and any other child things, like modifying the http request itself for instance)

[RobinTail]

perhaps i need to read the code some more - does the middleware abstraction for express-zod-api not include a parallel to "next"-style middleware?

Not really. There is no next.
All middlewares are ran in band (one by one) and their returns are combined into options object, supplied later to an endpoint.
Those options are meant to hold the context. Middlewares have access to request and response, while endpoints only have access to the context of options.
Logger instantiated or taken from the config only once in the beginning, and then supplied into all handling entities.

So semantically and conceptually, options is the only right way to hold anything context related, like the child logger as well.

I also had a thought on allowing logger in config to be a function, that accepts the request and returns the logger, which could achieve exactly what you want, but I'm not sure it's a right way, because:

• basically, it's just a particular case of a middleware's job, so I'd rather prefer to use the existing flow;
• this would create uncertainty as to what constitutes a logger in each specific case.

Therefore, I prefer the idea of extending the availability of options up to the ResultHandler, which will thus allow access to the child logger as its particular case anywhere, @elee1766

[elee1766]

@RobinTail

ok that makes sense.

is it the "correct" thing to do in typescript world then to extend the options object with a global type declaration that includes the logger and any other context-scoped parameters, then pass this same options type to my downstream services?

[RobinTail]

is it the "correct" thing to do in typescript world then to extend the options object with a global type declaration that includes the logger and any other context-scoped parameters, then pass this same options type to my downstream services?

Well, I believe there a multiple ways for doing things correctly, @elee1766 .
However, if by "downstream services" you mean endpoints, then the type declaration of options might be excessive, because express-zod-api cares about it automatically by inferring the type of returns of all the middlewares attached to the EndpointsFactory. Let me show you what I mean:

So, endpoints produced on the factory are already aware of the options type.

This, however, will not work for ResultHandler, that I'm thinking to equip with the options as well in the PR #1466 based on the previous discussions.

[RobinTail]

You know, I'm gonna try preparing one more PR with an alternative solution to this problem, and then we'll compare them.
@elee1766

[elee1766]

is it the "correct" thing to do in typescript world then to extend the options object with a global type declaration that includes the logger and any other context-scoped parameters, then pass this same options type to my downstream services?

Well, I believe there a multiple ways for doing things correctly, @elee1766 .
However, if by "downstream services" you mean endpoints, then the type declaration of options might be excessive, because express-zod-api cares about it automatically by inferring the type of returns of all the middlewares attached to the EndpointsFactory. Let me show you what I mean:

So, endpoints produced on the factory are already aware of the options type.

This, however, will not work for ResultHandler, that I'm thinking to equip with the options as well in the PR #1466 based on the previous discussions.

the issue I guess is I'm leaving the zea handler world. I think the imagined workflow is that everything is in handlers but I've left that world .

basically I have a bunch of these in a map separated by name

import { Logger } from "pino";
import {market} from "src/tdefs"

export abstract class Market {
  abstract GetStatus(params: {}): Promise<market["MarketReport"]>;
  abstract GetPriceQuote(log: Logger, params: market["QuoteParameters"]): Promise<market["PriceQuote"]>;
  abstract GetExecutionInformation(
    log: Logger,
    params: market["ExecutionRequest"],
  ): Promise<market["ExecutionInformation"]>;
}

these market types are reflected from a file of zod defs, and are the same zod types that I pass into handler definitions later.

import * as Zmarket from "src/zdefs/market"
import * as Ztypes from "src/zdefs/types"
import { z } from "zod"

type StripPrefix<
  TPrefix extends string,
  T extends `${TPrefix}${string}`,
> = T extends `${TPrefix}${infer R}` ? R : never;

type tmarket = typeof Zmarket
export type market = {
  [P in keyof tmarket & `Z${string}` as StripPrefix<"Z",P>]: z.infer<tmarket[P]>
}

type ttypes = typeof Ztypes
export type types = {
  [P in keyof ttypes & `Z${string}` as StripPrefix<"Z",P>]: z.infer<ttypes[P]>
}

and a handler looks like this

       swap_quote: globalFactory.build({
          method: "post",
          input: ZQuoteParameters.extend({
            marketId: z.string(),
          }),
          output: ZPriceQuote,
          handler: async({input, logger}) => {
            let {marketId} = input
            if (marketId === 'default') {
              marketId = defaultMarket;
        }
        const market = this.markets.getMarket(marketId);
        if (!market) {
          throw createHttpError(404, 'market not found')
        }
        const result = await market.GetPriceQuote(logger, input);
        return { ... result, market : marketId }
        }
        }),

so I'm trying to pass information from the zea handler to the class implementation so I can trace the request across. so my thought would be to define a global options type that includes my logger and then pass the options object as the first argument, which should pass the type assertion since if the middleware exists, the options type will include the logger.

perhaps there is a better way to do this ? I couldn't find a reliable way to "call" an endpoint from another so markets are not in zea handlers

[RobinTail]

The feature of childLoggerProvider is now available in recently released version 16.4.0 🚀
, @elee1766

[RobinTail]

Update on this topic.
Starting v19.2.0 .child() method added to the built-in logger

[elee1766]

oh that's sick.

i'll try it out soon :)