Custom Formatters

[hartbit]

One thing I really miss from the current revision of the API is separation between formatting and log "handling". As a user of the API, I usually want to use ready-made LogHandlers (multiplexer, file, stdout) while still controlling the formatting of the log messages. For reference, the basic example from winston, one of JavaScript's most used logging framework shows this in action:

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.json(),
  defaultMeta: { service: 'user-service' },
  transports: [
    //
    // - Write to all logs with level `info` and below to `combined.log` 
    // - Write all logs error (and below) to `error.log`.
    //
    new winston.transports.File({ filename: 'error.log', level: 'error' }),
    new winston.transports.File({ filename: 'combined.log' })
  ]
});

//
// If we're not in production then log to the `console` with the format:
// `${info.level}: ${info.message} JSON.stringify({ ...rest }) `
// 
if (process.env.NODE_ENV !== 'production') {
  logger.add(new winston.transports.Console({
    format: winston.format.simple()
  }));
}

[hartbit]

Or perhaps LogHandlers should just come with customisable formatting 🤷‍♂️

[ktoso]

I believe this is up to LogHandler implementations to leave configurable, and those are to be provided outside of this bare-bones API. So yes, but I don't think the proposal needs any changes to acomodate this -- we could document that this is the intent however (In general I think some more docs about intended usage would be useful as people go to adopt these APIs). WDYT?

[hartbit]

I think I agree: I could see myself implementing a DatabaseLogHandler that doesn't do any formatting and stores each value in different columns, so I see the reasoning leaving that to LogHandler. But perhaps we should still provide a consistent way for LogHandlers that do output to text to provide formatting customisation, instead of each handler doing it their own way?

[weissi]

What @ktoso says. I would expect that over time there’ll be slightly higher level packages that will handle this.

How this might go is that very soon after we release this, there will be some monolithic LogHandlers that do everything, formatting, shipping logs off, etc.

Then at some point I hope that there will be a slightly higher level package that unifies the commonalities from the monolithic LogHandlers but makes both formatting and shipping off the logs configurable. So basically we might have the API package (this) and then a ‘logging backend tools’ package that can be used to create really awesome LogHandlers without duplicating all the boring stuff.

The one thing that I see this package providing value is having a common API and no longer delaying the ecosystem. I think there are a lot of discussions to be had how to write a great LogHandler, how to format, how to persist, etc. But I don’t think we can wait until we decided on all those without ever having run or even written the code. I think it’s more worthwhile to start somewhere (an API) and then to fill in the implementation as we all learn. The cool thing is that as soon as a new, better implementation of a logging backend comes along we just need to change one line LoggingSystem.bootstrap(newShinyThing) and we have adopted the new thing.

That’s at least the hope.