Versioning and version negotiation

[yuji...@gmail.com]

Hi,

I am wondering what's the recommended way of doing versioning and version negotiation in gRPC? The use case I can trying to solve is:

1) I have an API server that uses gRPC. The API might have multiple versions.

2) The client has multiple versions too.

3) I want the newer version of the client to smartly pick the API version (through some negotiation) depends on the API version that the server supports. For instance, if the server exposes an older version of API, the client will choose to use the old API to talk to the server.

In the REST, the standard way of supporting that is through Content-Type negotiation:

https://stackoverflow.com/questions/10742594/versioning-rest-api

I am wondering if there is anything equivalent in gRPC?

Thanks!

- Jie

[Carl Mastrangelo]

Have you considered not having versions and just keeping a single proto file?  When you make a service, pretty much anyone can call the methods on it, not just the clients you make.  Because of this, you end up having to support all the old methods on your service anyways.  Service definitions tend to only ever get new methods rather than removing or changing existing ones, so the idea of versioning doesn't usually make sense.

If there is an old version of a client trying to connect it wouldn't know about the new, proper methods to call (or else it would have been updated to do so).  Splitting your api into versions doesn't really fix having old clients around so you end up having to support two versions vs. one.