This is kind of a question and a proposal.
I recently looked into switching loggers for a few our phoenix applications from a file logger to a stdout json logger.
While doing some research, I noticed a few different patterns in use. The first was to wrap the existing Logger module and the second was to create a backend.

I don’t think wrapping Logger is ideal since a lot of other packages have dependencies on Logger and could be calling it directly.
This would also require the project owner to be on the lookout for any direct use of the module in any future changes.

Creating a backend seems to be the intended pattern but I think this could be improved. I see a definite separation between outputting (stdio, file, tcp/udp, etc)
and formatting, but this seems to be coupled in a lot of existing logger packages (e.g. logger_json_file_backend).

Have I been looking at this wrong? If not, here’s my proposal: Let’s create a behavior for formatters, break out the default formatter from console, and determine formatters from configuration.

config :logger,
  backends: [{Logger.Backends.Stdout, :stdout_logger}]

config :logger, :stdout_logger,
  level: :debug,
  metadata: [:request_id],
  formatter: Logger.Formatters.Json

Doing something like this while remaining backwards compatible with the existing :console backend and :format configuration might be a little tricky.
We might also want to break out common functionality into the utils module or a helper. This would include things like handling metadata and what not.
Thoughts?