Looking for advice on structuring my multiplatform...

# multiplatform

[Wolf Logan]

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)?

[Wolf Logan]

For types that are entirely under my control, I can simply move the data class definitions into the common library But in some cases I have types that encapsulate other, platform-specific types.

[Wolf Logan]

I'm new to this approach for Kotlin development, and I'm hoping to learn from others' experience

[Casey Brooks]

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.

[Kris Wong]

and fold in kotlinx.serialization

[Wolf Logan]

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

[Kris Wong]

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

[pablisco]

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.

[pablisco]

Ah! I ended using a plain property (and use the country name) 😅
https://github.com/pablisco/virustrend/blob/master/domain/models/src/commonMain/kotlin/org/virustrend/models.kt#L79

[pablisco]

And use enums instead:
https://github.com/pablisco/virustrend/blob/master/domain/models/src/commonMain/kotlin/org/virustrend/Country.kt#L203
I went through a couple of versions hehe

[Wolf Logan]

great examples, thanks!

[pablisco]

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 🙂