Open Tudyx opened 1 year ago
Chiming in from OneSignal - we have found that across engineering we burn a non-trivial amount of time writing conversions simply to get all of the Option
handling out of our business code. It's been extensively discussed elsewhere on the issue tracker how tedious and time consuming this can be, so I'll just leave it at that.
We would love to see a mechanism for the code gen to obviate the need for this Option-eliminating boilerplate that comes with every new RPC endpoint. The field_behavior
attributes are generally a great solution to this.
We are using tonic in a service handling user commands. These commands are used later in our business logic and have required
Message
field which is generated byprost
asOptional
as stated in the proto3 specs.Google has a workaround for having required fields while still respecting the proto3 specs, they are using field_behavior.
The syntax looks like this.
They are using it a lot, for instance in pubsub proto.
The idea is not to make the field optional if its "tagged" with
[(google.api.field_behavior) = REQUIRED];
.Related to https://github.com/tokio-rs/prost/issues/521