3 ms·
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 break
by jillesvangurp 4y ago
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?
- TeeWEE 4y ago> I mitigate it by configuring the serializer to be tolerant of new or missing keys, enum values, et 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 https://github.com/grpc/grpc-web Transcoding to HTTP is also supported: https://cloud.google.com/endpoints/docs/grpc/transcoding https://cloud.google.com/endpoints/docs/grpc/transcoding https://cloud.google.com/blog/products/api-management/understanding-grpc-openapi-and-rest-and-when-to-use-them https://cloud.google.com/blog/products/api-management/unders...