When using the service defintion of the generated code, there is a mismatch between the high level types and the underlying thrift binary serialization strategy. The canonical example for Scala/Java is UUID or ZonedDateTime, leading to implementors either polluting their service traits with Int and Long's or using Strings when the customer of those APIs often would like to work in higher level types such as UUID, ZonedDateTime - or their own custom such as UserID.
There is multiple ways this could be implemented, however there seems to be an chicken-and-egg problem by the thrift definitions not yet being compiled and generated yet, when loading any custom adapter, therefore the trait for an adapter likely have to be at a lower level.
Please let me know if this is completely off the rails or if something like this is already possible today. I would also like to reference the Java / XML solution, XmlAdapter
When using the service defintion of the generated code, there is a mismatch between the high level types and the underlying thrift binary serialization strategy. The canonical example for Scala/Java is
UUID
orZonedDateTime
, leading to implementors either polluting their service traits withInt
andLong
's or usingString
s when the customer of those APIs often would like to work in higher level types such asUUID
,ZonedDateTime
- or their own custom such asUserID
.There is multiple ways this could be implemented, however there seems to be an chicken-and-egg problem by the thrift definitions not yet being compiled and generated yet, when loading any custom adapter, therefore the trait for an adapter likely have to be at a lower level.
Please let me know if this is completely off the rails or if something like this is already possible today. I would also like to reference the Java / XML solution, XmlAdapter