Boilerplate code - Declaring Codecs often requires more Codecs

[MarconZet]

When declaring Codec[A], if class A has a field of class B, then Codec[B] must also be declared.

[PawelLipski]

Let's assess https://github.com/plokhotnyuk/jsoniter-scala in this context

[MarconZet]

Let's assess https://github.com/plokhotnyuk/jsoniter-scala in this context

Hmm...
Jsoniter philosophy seams difrent form Borer.
JsonValueCodec[A] is "fat". It contains all information required to serialize and deserialise class.
Borer's codeces are more like layers. One codex feeds into another, breaking down object into simpler and simpler elements.

[PawelLipski]

Hmmm okay but jsoniter claims that it can cooperate with Borer somehow (generate Borer-compatible codecs?)... this is probably going to be useful for our use case (?)

[PawelLipski]

@sirthias can you think of any ready solution here? Like jsoniter-scala or sth else Magnolia-based?

[sirthias]

borer derivation is intentionally not fully "auto-magic", because this often leads to issues down the road.
See this ticket for example: softwaremill/magnolia#79

Consider this snippet for example:

case class Foo(int: Int, qux: Qux)
case class Bar(qux: Qux)
case class Qux(...)

If deriveCodec[Foo] would automatically also derive the codec for Qux then this Codec[Qux] wouldn't be visible during derivation of Codec[Bar]! Which means that deriveCodec[Bar] would generate Codec[Qux] again!
And you wouldn't see this duplication anywhere!

In this small example this might not be an issue but for large model hierarchies these kinds of invisible duplications can create huge amounts of code, that takes a long time to compile and can create a number of strange issues.

In our experience it's indeed better to manually cache codecs for all types in implicit vals, which takes only a single line.
This results in the minimal amount of code, fastest compilation and runtime performance as well as full transparency on which type classes are actually available and which aren't.

[PawelLipski]

Okay, that's a valuable point... so maybe we @MarconZet should not go down this rabbit hole indeed, and instead focus on #5 to prevent runtime errors