Hi all! i am currently looking at this ask <https:...

# arrow-contributors

[mitch]

Hi all! i am currently looking at this ask https://github.com/arrow-kt/arrow-integrations/issues/45 and am gathering inputs from folks here before I change anything. That issue seems to be a low hanging fruit which also doesn’t have a universal answer due to json & type unions. On one hand my initial instinct is to go with the semantics done in argonaut / circe which currently serializes as a configurable keyname e.g.

data class Foo(val foo: Either<FooLeftADT, FooRightThing>)
// serializes to
{
  "foo": {
    "left": ${leftValue.asJson}
    // or "right": ${rightValue.asJson}
  }
}

That shape is awkward but the codec above guarantees roundtrip. On the other hand, I also realize that Helios (which is by the way is a great library!!) is doing it without i.e.

// which yields
{
  "foo": ${leftValue.asJson}
    // or "foo": ${rightValue.asJson}
}

personally I do see the temptation of breaking codec laws in the second / helios variant. They are less awkward and more universally acceptable when we’re talking about microservices interop. However, a similar proposition was raised to circe and was declined - most likely due to the codec being unlawful. Of course, at the end of the day, both can be correct, and there’s no stopping us to implement a configurable knob for users to switch between one and the other.

I don’t personally serialize Either<L, R> myself. I normally advocate folding it to a proper sealed type in the internal projects in my company so to avoid this problem altogether and also make sure the api contract plays well with various microservices written in multiple languages / paradigms. Having said that I’m somewhat indifferent.

by the way the same thing can’t be said for ior

keen to hear Arrow arrow crews’ thoughts.

[raulraja]

Thanks @mitch for the thoughtful explanation. I’m also of the opinion that Either should not be serialized but for users that wish to do so the circe strategy I think it’s a better option