Open sahas-n opened 2 years ago
You enter the type name in the top text box.
If it is a recognized type (part of the known schema for the selected method), it will populate the entry as a form for the message type. In the screenshots, since the selected type is StringValue
, it just provides a simple text entry for the contained string value. But if you enter a more complicated type, it will turn into a form.
If you enter a message name that is not recognized, then instead of a form for that message type, you get a text area and must enter the value as a JSON object.
@jhump I have generated a descriptor set with more message types (that are not direct dependencies from the gRPC Service) and expected them to appear as an entry option, but it does not appear. Isn't that supported?
@AFMiziara, not today I'm afraid. It would be possible to add though. The client would need to send a request to the server to get the schema for a single message type, which it would do when an unrecognized type name is entered. It could then use the type (if the server knows it) to populate the form, just as it already can today for known types.
But currently "known" types include only the ones in the transitive closure of the method that it downloads from the server and the "well-known" types (various messages in google.protobuf
package).
@jhump I solved it in way a little bit different. I let the user to specify a file containing these Server "known" types (message types) that are not direct dependencies of any service. So I can get their descriptors and deliver to the UI all the schemas properly. It worked for me.
Hopping in to say this would be valuable to me, too. I have an interface that uses an Any type layer for abstraction like MIziara describes.
One oddness to me is if I use grpcurl
to issue the raw command that grpcui
displays, verbatim, it seems grpcurl (v1.8.9) can parse the abstracted Any response object into sensible fields, while grpcui (v1.3.3) leaves the Any field in an unencoded state. Would you expect different behavior for this?
Hopping in to say this would be valuable to me, too. I have an interface that uses an Any type layer for abstraction like MIziara describes.
One oddness to me is if I use
grpcurl
to issue the raw command thatgrpcui
displays, verbatim, it seems grpcurl (v1.8.9) can parse the abstracted Any response object into sensible fields, while grpcui (v1.3.3) leaves the Any field in an unencoded state. Would you expect different behavior for this?
also experiencing something similar where if i provide grpcurl the proto used in the any via -proto
in addition to reflection it works as expected, but the same flags don't work in grpcui
Most of our grpc APIs use google.protobuf.Any. However, I couldn't find a clear way to fill the "any" fields via grpcui. A default String type is populated for the any field. Is this field supported by grpcui? How can I pass the value to these any fields via grpcui?