The article does not actually explain how to do inheritance. In case you are wondering, the answer is using sealed classes.

Some neat things with data clases (vs. e.g. Java's records):

- default values for parameters

- if you use vals, your data classes are immutable

- copy constructor that has the same parameters as the constructor with their current values as the default value.

- destructuring values

- extension and delegated properties. Those are not limited to data classes of course but they are really nice to use with data classes.

Kotlin multi platform and data classes are actually a nice combination btw. We have a spring boot project with a Kotlin multi platform API client that we can consume on Android, IOS, in a Browser and in our integration tests for the server. Exact same code working exactly the same way on IOS native, in a browser, or on Android and the JVM. It uses ktor client for http communication, and kotlinx serialization for json parsing. Works great.

How do you deal with schema versioning?

We use the exact same setup. However older client version often trip over server schema changes.

While this is a generic problem, it’s harder to prevent when your models it’s not built into your network data contract.

That’s why we considering using grpc which has backwards compatibility support on its design. Things can still break if you delete endpoints, but at least it’s contained to the idl file.

I basically don't version schemas currently. We do version our library of course. So you have to opt into using a new version.

But managing compatibility breaking API changes is a bit of an issue of course. Not just for Kotlin.

I mitigate it by configuring the serializer to be tolerant of new or missing keys, enum values, etc. The defaults for this are actually a bit dangerous/wrong IMHO. Also, most new properties that we add are nullable and default to null. This way we can safely deal with values not being there. And we use deprecations before removing anything from the API (which are nice in kotlin because you can automatically fix them in intellij with replace patterns). There are a few other things you can do. Like implementing some good contract tests, etc.

We actually considered grpc at some point but decided against it as being a bit too limiting and mobile centric at the time. Also, grpc in a browser was not well supported at the time we looked. Maybe that has changed?

Good point, we do that too.

> We actually considered grpc at some point but decided against it as being a bit too limiting and mobile centric at the time. Also, grpc in a browser was not well supported at the time we looked. Maybe that has changed?

Its supported: https://github.com/grpc/grpc-web

Transcoding to HTTP is also supported: https://cloud.google.com/endpoints/docs/grpc/transcoding

https://cloud.google.com/blog/products/api-management/unders...