> Only using optional fields and coding for missing fields helps us ensure our services are resilient to version mismatch.
I've seen this before and I've always been suspicious of it. So if version 1 has field r,g,b and version 2 has fields r,g,b,a and i use version 1 in a version 2 stack any data on alpha field is ignored. O.k. so you didn't get a stack trace, but is that working software?
Totally agree. I think the microservices thing is actually a distraction from the real concepts at play. As a good thought exercise, imagine if the same thing happened within a single process.
If code was written that expected version 2, and a version 1 object was provided, the static type checker would catch it at compile time.
But with microservices, there is no static type checker and you're essentially coding as if you were in a dynamically typed language.
Hopefully you've at least set up integration tests where you can test the service you're about to deploy against the others, but I think in many microservice situations the only integration testing that happens is in production.
Yup. Version APIs and once you publish a spec for them and have other services relying on those APIs, changes should probably be a new version. Stuff like OpenAPI (Swagger) can also help: https://openapis.org
I've seen this before and I've always been suspicious of it. So if version 1 has field r,g,b and version 2 has fields r,g,b,a and i use version 1 in a version 2 stack any data on alpha field is ignored. O.k. so you didn't get a stack trace, but is that working software?