Looking for advice on structuring my multiplatform project to help manage JSON contracts. I've got a project with three components: a server-side (JVM), a client-side (JS), and a common library. I have certain REST services exposed on the server side that are consumed by the client side. I want to standardise the JSON serialisation of types that are passed across the REST endpoints. Is there a good way to make use of the common library to enforce serialisation so that I don't have to have multiple type declarations (that can get out of sync)?

I’ve tackled a similar problem with Orchid (although its not server-client serialization, but just general abstraction) by setting up the models as interfaces in the Common module rather than data classes, and then the platform-specific modules can write their own data classes to implement the interface.

and fold in kotlinx.serialization

Is there a reference somewhere for best practice using

kotlinx.serialization

in this context? It's the serialisation that I'm most concerned about tying down, since (historically) our team has had bad experiences with JSON contract drift, and I want to offer them a good solid strategy for success here

best practice is, make sure you don't have any required properties that are not in your interface 🙂

With serialisation, from experience, best to keep the models simple and reflect the API data with primitive types (or other API data classes). Then, any more complex objects can be accessed with extension properties which can be tagged with the

actual

keyword with different implementations if needed. One use case I had was country codes. On my model I had just the code and then the country was resolved to a sealed class with a fallback "Unknown" data class (part of the original sealed class) so I was able to bridge the server dato to something typed. I started originally making custom serializers, but they are not quite there yet for all cases, it was safer to keep things simple 😁 One downside is that the country is resolved at time of usage instead of at time of parsing, however it means that they are lazily initiated so that can also be good, depends on the case. An alternative is to do lazy properties instead of an extension property if it becomes a problem.

great examples, thanks!

This other one is what I was talking about using actual: https://github.com/pablisco/virustrend/blob/master/app/utils/color/src/commonMain/kotlin/org/virustrend/color/PlatformColor.kt So it’s easy to jump from and platform versions, specially with the factory operator 🙂