Hacker News Reader

Comment by malkia | Hacker News Reader

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.

View on HN

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 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.

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

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.

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.

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.

Reply on news.ycombinator.com