Clarify the aims of this library

[aucampia]

Does this library aim to be:

1. A facade loosely coupled with a driver for the facade that can be exchanged for other drivers.
2. A facade tightly coupled with a driver for the facade that has to be used in conjunction with it.

This is important to understand, as if the case is 2, then it may be better to use a facade not coupled to a driver in things like go-identity-lib.

See also:

• https://github.com/coopnorge/go-identity-lib/issues/75
• https://github.com/coopnorge/go-identity-lib/issues/74
• github.com/go-eden/slf4go's architecture

[bendiknesbo]

We have now gotten to a point (see #75), where we need to make breaking changes to go-logger to provide better value for our services.

Options for go-logger:

1. Rewrite it without exposing ANY implementation-details (go-logger can in the future swap between e.g. logrus/zerolog/zap without making any breaking changes), keeping almost the same API as today to reduce upgrade-friction.
   • Pros:
     1. We can easily change the logging-library we use, if the selected one becomes (relatively) slow, abandoned, or insecure.
     2. Even though the API will change (e.g. logger.WithField(a,b) will return a struct instead of an interface), it should produce the minimum amount of code-changes required in our services.
     3. If we want, we may be able to expose a way to access the raw API's from the selected log-library functions marked as experimental.
   • Cons:
     1. To use new logging-library-features, they need to first be added to the library, and then they can be used in different services. (This should not happen often, as there is only a certain amount of stuff a logging library should do.)
2. Rewrite it to be tightly coupled to a specific logging-lib (e.g. logrus/zerolog/zap), and trim it down to basically only defining a standard way of instantiating/configuring the third-party logger.
   • Pros:
     1. Quick use of new features.
   • Cons:
     1. Every service manually needs to swap logging-library, if we want to change. This includes moving to a different API.

---

No matter which solution we opt for, these are some things we should take into consideration:

• go-logger should probably provide different adapters for commonly used packages, such as GORM, Datadog, Echo, Resty, to be able to log their messages using go-logger.
• go-logger should probably provide a way to configure a backend for the new log/slog package, so that if a library uses log/slog, it will go via go-logger.
• go-logger should probably use a strongly typed fields-system, other than what we have today with logrus' Fields.

If we go for option 2, we would have to select a specific logging-lib before rewriting go-logger. Our current logging-lib logrus, is in maintenance mode, and benchmarks as one of the slowest logging solutions on the market for go, so we might want to move away from logrus at the same time.

---

I strongly lean into going for option 1.

[bendiknesbo]

I created a POC for option 1, while swapping to Zap: #76

[bendiknesbo]

I also created a POC for option 1, without swapping away from Logrus: #77

[bendiknesbo]

With the recent merge of #77 , we have decided to go for option 1.