3 ms·

Thanks for the response! These are very good references. I like the breakdown of message and/or service definitions into separate files so it is easy to browse

by bruth 9y ago

Thanks for the response! These are very good references. I like the breakdown of message and/or service definitions into separate files so it is easy to browse through the repository. I am assuming the version bump (v1 vs. v2) occurs when you introducing breaking changes to the API? I am aware that protobuf does a good job at allowing forwards and backwards compatibility at the message level..

doh 9y ago
Correct on the versioning. We internally treat protos as an immutable descriptions of our API interfaces. That means whenever we need to change anything (outside of bugs), be it adding a new field, or changing the order, renaming fields, changing types, ... we start a new version. We also use a lot of inheritance of non-default types (timestamps, errors, ...) so it's important to make sure that we don't break anything for others.
- bruth 9y ago
  Interesting so adding new fields even.. I suppose there is quite a bit of planning and iterating on the interface before making it public to reduce churn? I understand doing that for backwards incompatible changes.
  - doh 9y ago
    We add new fields (or redesign existing protos) very sporadically. We also don't have fully automated process to deal with a change in a proto within all projects so by using new versions we can signal to the developers that they should eventually adopt it. We are actively using 5 languages that have to deal with the changes, so we found it easier overall to do it this way.