[86J8oyZv]

1) Having worked for a company that did this (after learning that it was an anti-pattern at a previous company)... Putting all Protobuf files in a single "registry"/repo is definitely an anti-pattern. You should put them in the repo that implements the service. That service is responsible for maintaining API compatibility between versions (i.e. keep field numbers "stable" and deprecate/update them so as not to break clients).

(If you want a "registry," the better approach would be to have something that uses all the services as dependencies to consolidate their protos.)

2) Going along with this approach, gRPC has a reflection service; most server implementations can expose this (I have personally done it with Tonic/Rust but I know Golang and Java bindings, probably Ruby and others, support it). If you use something like gRPCurl against a server with reflection, the only "path flags" you have to worry about are, like... just the method names. It can't really get more terse than it is with gRPCurl and gRPC reflection, though autocomplete would be nice to have I guess.

The basic intent of gRPC - indeed, its advantage over JSON - is to promote composable, decoupled services. Unless you're monorepoing all your services, putting all protos in a "registry" type repo, that everything depends on, only makes things harder for everyone that needs to do things with those protos.