I think there are minor quirks with some of our protobuf files and definitions. Nothing is broken, but some best practices and guidance to be consistent within the project could be applied. Some rules especially apply to ensure multi-language compatibility. These are a few points to consider, there are others:
[ ] Enums should be prefixed with TYPE_ Uber Styleguide, Enums , Google Style Guide, Enums
[ ] Enums should have a zero value with _UNSPECIFIED / _INVALID prefixed
[ ] gRPC method options (like google.api.http) use historical optional delimiters when they use the aggregate syntax (protobuf TextFormat) to set option messages values.
As always "consistency is key" and we might like to define our own style and best practices for cloudstate. Perhaps our "Formal Spec" #119 Draft-PR could be used to address these issues. Therefore I leave the PR #511 as a Draft-PR to track changes and collaborate on succeeding changes on other places in the code or documentation.
Also, we could use a linter to ensure consistency (buf).
I think there are minor quirks with some of our protobuf files and definitions. Nothing is broken, but some best practices and guidance to be consistent within the project could be applied. Some rules especially apply to ensure multi-language compatibility. These are a few points to consider, there are others:
Those rules and others are from both Uber Styleguides and Googles Protocolbuffer Style Guide: https://developers.google.com/protocol-buffers/docs/style https://github.com/uber/prototool/blob/dev/etc/style/uber1/uber1.proto https://github.com/uber/prototool/blob/dev/style/README.md#enums
As always "consistency is key" and we might like to define our own style and best practices for cloudstate. Perhaps our "Formal Spec" #119 Draft-PR could be used to address these issues. Therefore I leave the PR #511 as a Draft-PR to track changes and collaborate on succeeding changes on other places in the code or documentation.
Also, we could use a linter to ensure consistency (buf).