Chapter 10. Service evolution with gRPC
Using an IDL like protobuf greatly simplifies a lot of things when it comes to defining your RPCs. The amount of boilerplate code required, especially when working with multiple languages, is greatly reduced. New fields can be safely added without worrying about breaking existing functionality or client behavior. This is only to name a few.
There are a number of cases, however, that require special attention when evolving an existing service. Any time you’re updating an existing implementation there are a set of constraints you need to work within. These include, but aren’t necessary limited to, maintaining binary and source compatibility, encoding/wire compatibility, and of course behavior compatibility.
Let’s take a look at each of these constraints and some of the details required to maintain a functioning service over time while making changes. If you’d like to jump straight to the code, the source code for this...
