https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
w

Wolf Logan

04/30/2020, 6:41 PM
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)?
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.
I'm new to this approach for Kotlin development, and I'm hoping to learn from others' experience
c

Casey Brooks

04/30/2020, 6:48 PM
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.
k

Kris Wong

04/30/2020, 6:49 PM
and fold in kotlinx.serialization
👆 2
w

Wolf Logan

04/30/2020, 6:51 PM
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
k

Kris Wong

04/30/2020, 7:02 PM
best practice is, make sure you don't have any required properties that are not in your interface 🙂
p

pablisco

04/30/2020, 8:43 PM
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.
w

Wolf Logan

04/30/2020, 8:47 PM
great examples, thanks!
👍 1
p

pablisco

04/30/2020, 8:56 PM
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 🙂
2 Views