4 ms·

Even in the simplest web apps you can encounter version mismatch when a client requests a response from a server that just updated.

• hansvm 2y ago
  Hence the advice to make that situation not happen. Update the client and server to support both versions and prefer the new one, then update both to not support the old version. With load balancers and other real-world problems you might have to break that down into 4 coordinated steps.
  • Joker_vD 2y ago
    That only really works if you control the clients, or can force them to update.
    • LoganDark 2y ago
      > or can force them to update. I've used a few clients that completely lock me out for every tiniest minor version update. Very top-tier annoying imho.
      • eru 2y ago
        But it does make the authors' jobs easier.
• seeknotfind 2y ago
  This implies an API where the server has a single shared implementation. Imagine for instance that the server implements a shim for each version of the interface, then there isn't a need for the null in the API. Imagine another alternative, that the same API never adds a field, but you add a new method which takes the new type. Imagine yet again an API where you are able to version the clients in lockstep. So, it's a decision about how the API is used and evolves that recommends the API encoding or having a null default. However in a different environment or with different practices, you can avoid the null. Of course the reason to avoid the null is so that you can statically enforce this value is provided in new clients, though this also assumes your client language is typed. So in the end, protobuf teaches us, but it's not always the best in every situation.