feat(zerolog): Add default log level helpers #26
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #25
I've tried a number of different approaches, but I think every single approach is just too much work and too much indirection for them to exist in a separate module.
It does not cut down on the amount of code, it makes the initialization of services more complex, the developers need to keep in mind and remember the environment variable names and how they work, how the kit is configured. All in all I don't think it's of sufficient benefit that it should be abstracted away.
Problem definition
Per the conversation on threads, the wish is to have a unified way of setting the logger to a specific level based on an environment variable.
As context:
An example to the latter as a minimum setup
This code only runs once every time a service starts up. Of this the parts that aren't service specific are
Possible solutions?
As an experiment I extracted all that into a
Baseline
function. To use that here's what the service needs to do:It does not cut down on lines of code, it hides implementation which makes figuring out what's happening harder than necessary to do. On the other hand it adds another dependency that we need, and it does not remove dependencies that we already have.
You also don't really know what comes out of
Baseline
, and it takes a lot more hops to figure out what the log level depends on, what its current value is. It's opaque.The PR also includes a bunch of other experiments, but in all cases the settings achieved in zerolog can be done in fewer lines with greater accuracy and precision directly than hiding it behind a kit function / module.
Personally I advocate for dealing with setting log levels in the services directly by using their already existing config structs and dedicating 3 lines in the setup code in all 4 places this is currently needed.
Marked the PR as draft because I do not have the intention of merging it in with current context. I am open to be persuaded if the problem definition warrants abstraction. I don't think the current one does.