3 ms·

Internally, google had best-practices (but could be outdated), that each RPC service function should take unique input message, and unique output message, and

by malkia 6y ago

Internally, google had best-practices (but could be outdated), that each RPC service function should take unique input message, and unique output message, and never reuse one, even if empty, or having same structure, at the cost of more writing. Later this allows one to change things independently.

jeffbee 6y ago
Wait but what about EmptyMessage and Any? Yes they're both terrible choices for any circumstance, but also widely seen.
- malkia 6y ago
  I dunno. I'm simply recalling what I remember as best-practices by memory, could've been wrong about some of them, but for my own protobufs that I use I keep the same practice.
  - malkia 6y ago
    But mainly for that reason, I would like to keep as much as backward compatibility, and if I have need to add a field, I can do it without changing some other function. (If need to, I'll add it in both places). Hard to tell really, for some things it might not make sense at all.
  - jrockway 6y ago
    No, you're right. EmptyMessage exists but you shouldn't make it an input or output to an RPC if that RPC might ever in the future accept or return arguments. Since people are super bad about predicting the future, just call it WhateverRequest and WhateverReply and if there are no arguments today, don't put any fields in those types. I would also not use Any as a request or reply type, but Any, in general, is fairly common in practical use.
fairenough42 6y ago
https://google.aip.dev/ https://google.aip.dev/ gives lots of advice for structuring a gRPC API. What you say is mostly in line with that, with some exceptions. For example https://google.aip.dev/135 https://google.aip.dev/135 suggests that a delete operation on a resource should normally return google.protobuf.Empty. Of course, this is implicitly a sum type; you either get an empty response or an error message. If you needed to return anything else, you're not just implementing a delete. Two exceptions they call out are soft-deletes (not just a delete...) returning the resource itself, and a delete that's a long-running operation.

by malkia 6y ago

jeffbee 6y ago

Wait but what about EmptyMessage and Any? Yes they're both terrible choices for any circumstance, but also widely seen.

malkia 6y ago
I dunno. I'm simply recalling what I remember as best-practices by memory, could've been wrong about some of them, but for my own protobufs that I use I keep the same practice.
- malkia 6y ago
  But mainly for that reason, I would like to keep as much as backward compatibility, and if I have need to add a field, I can do it without changing some other function. (If need to, I'll add it in both places). Hard to tell really, for some things it might not make sense at all.
- jrockway 6y ago
  No, you're right. EmptyMessage exists but you shouldn't make it an input or output to an RPC if that RPC might ever in the future accept or return arguments. Since people are super bad about predicting the future, just call it WhateverRequest and WhateverReply and if there are no arguments today, don't put any fields in those types. I would also not use Any as a request or reply type, but Any, in general, is fairly common in practical use.

fairenough42 6y ago

https://google.aip.dev/ https://google.aip.dev/ gives lots of advice for structuring a gRPC API. What you say is mostly in line with that, with some exceptions. For example https://google.aip.dev/135 https://google.aip.dev/135 suggests that a delete operation on a resource should normally return google.protobuf.Empty. Of course, this is implicitly a sum type; you either get an empty response or an error message. If you needed to return anything else, you're not just implementing a delete. Two exceptions they call out are soft-deletes (not just a delete...) returning the resource itself, and a delete that's a long-running operation.