Improve LogEncoders UX

[kubukoz]

Currently, whenever you create things, you need a number of imports for their log encoders. While the goal of being agnostic wrt libraries and encodings, the user experience of getting these loggers could be improved.

Ideas:

• make show encoders importable directly from the companion object of the LogEncoders type, e.g. import LogEncoders.show._
• have uber-imports for e.g. circe which require only one import for all possible encoders you might need. If this is currently not possible due to dependencies being split across modules (e.g. KPL and kinesis-client modules), perhaps there's a way around it
• maybe make encoders explicit, and default to "show" everywhere

[etspaceman]

have uber-imports for e.g. circe which require only one import for all possible encoders you might need. If this is currently not possible due to dependencies being split across modules (e.g. KPL and kinesis-client modules), perhaps there's a way around it

The tough thing about this is that we are making encoders for the underlying types from things like the AWS Java SDK or smithy4s. If we were to do an uber-import, that would combine all of the kinesis dependency which would likely be undesirable.

make show encoders importable directly from the companion object of the LogEncoders type, e.g. import LogEncoders.show._

We can do that with show, but if we want to keep circe as a separate module, I cannot do that with circe instances.

maybe make encoders explicit, and default to "show" everywhere

This feels reasonable

[kubukoz]

We can do that with show, but if we want to keep circe as a separate module, I cannot do that with circe instances.

yeah. but you might still have an uber-import for it!

The tough thing about this is that we are making encoders for the underlying types from things like the AWS Java SDK or smithy4s. If we were to do an uber-import, that would combine all of the kinesis dependency which would likely be undesirable.

can we do something like "schematic" and have Schemas in these library-specific modules, and have a circe module with an interpreter that deals with the schemas? I guess it depends on how difficult these schemas would be to write / derive.

[etspaceman]

can we do something like "schematic" and have Schemas in these library-specific modules, and have a circe module with an interpreter that deals with the schemas? I guess it depends on how difficult these schemas would be to write / derive.

Potentially, Smithy4s's classes could be used as some sort of bridge for the API classes to avoid having to maintain the schema directly.