Get proto key for Any message serialization

[smolijar]

Is your feature request related to a problem? Please describe.

I could not find an API in any of the packages to get a key for a message for Any serialization and keys must be curated manually.

This becomes extremely helpful when handling status details.

I browsed the generated messages and the only places where the name is used seem to be dispayName in debug and registration of symbol via some google lib, which could probably be used for that?

Describe the solution you'd like

Java has an API for that, as shown in here: ProtoUtils.keyForProto

[murgatroid99]

The Node libraries do not have an exact equivalent of ProtoUtils.keyForProto because they do not have the equivalent key system that it interacts with. You will need to directly use a protobuf library to serialize and deserialize those messages.

Regarding the status details information in the grpc-status-details-bin metadata value in particular, there is also issue #184 about decoding that value, and one comment there links to a package that can decode it.

[smolijar]

do not have the equivalent key system

That means that I need for similar functionality a manually curated map of (field names, serialization function) on server and (field names, deserialization function) on the client? Are you aware of an issue about this key system for node protobuf, so I know if this feature is undesired on not implemented?

Thanks for the response. We can close I think, issue should potentially continue in protobuf.

[murgatroid99]

Before this issue, I have simply never seen any request for this kind of support for including multiple protobuf-serialized messages in metadata. So I don't know of any particular problem with this feature other than a general lack of demand. If this feature is specific to gRPC, which it seems like it might be, it would probably make sense to have the feature request here, and implement the feature in the grpc-tools and/or @grpc/proto-loader packages in this repository. Either way, we'll need to get a more detailed understanding of this use case to know what that implementation should look like.