1

Now that protocol buffers 3 has support for optional fields which lets you test whether the field was set or not, are FieldMasks still useful?

For instance, when implementing an Update method in gRPC which allows the client to update only the fields that they pass, should the method take a message with optional fields or a FieldMask? Is it a matter of personal preference? Or is there a benefit to one of them?

We also want to expose the gRPC API as a JSON/HTTP API using either grpc-gateway or envoy with the grpc_json_transcoder filter. Do these have a preference with either pattern?

niltz
  • 1,014
  • 11
  • 28

1 Answers1

1

After much trial and error, I've come to the conclusion that FieldMasks are still required if your resource has repeated or map fields. These can not be marked as optional and have no ability to check for presence. So in these cases you need a FieldMask, and in order to remain consistent in your update requests you may as well use FieldMasks everywhere.

FieldMasks also allow you to use your existing protocol buffer message types without having to mark fields as optional.

niltz
  • 1,014
  • 11
  • 28
  • Also, `optional` makes no difference for message-typed (non-scalar) fields. So you have no way to reset such a field via `Update` using `optional`. – Alex Che Jun 02 '23 at 16:34
  • repeated (and map) fields don't work well with FieldMasks since the FieldMask cannot cannot drill down into those fields. – Alex O Aug 28 '23 at 20:08