Reputation: 724
In protobuf docs its stated that:
Deleting fields can cause serious problems if not done properly.
When you no longer need a field and all references have been deleted from client code, you may delete the field definition from the message. However, you must reserve the deleted field number. If you do not reserve the field number, it is possible for a developer to reuse that number in the future.
What I don't understand about is that, I am using protobuf encoding for communication in between my client and server. So client encodes the data with protobuf, sends the request over the network, and the server decodes the body of the request with protobuf, and executes some business logic. And the client is the only one that will be communicating with this server so there will be no consumer of this server which is possibly outdated. Whenever server messages are updated, client will naturally be always up-to-date.
Considering all the above, why would removing a field or reordering field numbers of messages, and generating new proto messages for both the client and server cause any problems?
Upvotes: 0
Views: 251
Reputation: 4610
[...] the client is the only one that will be communicating with this server so there will be no consumer of this server which is possibly outdated. Whenever server messages are updated, client will naturally be always up-to-date.
If you assume this you can basically do whatever you like in any encoding.
Unfortunately it's wrong most of the time. You just need to roll back a faulty client or server, or have a minor time difference of updating client and server (because the server is still terminating, while the client is already new), and you are in the situation where clients and server versions don't match.
One of the beautiful things about Protocol Buffers is that you have free backwards and forwards compatibility, when you just follow some simple rules.
Upvotes: 1