Add RequestType and ResponseType metadata to method definition #408
Conversation
|
Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement. After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.
Regards, |
|
CLA Signed. |
|
Different take on #378. |
| @@ -37,6 +37,8 @@ export interface MethodDefinition<RequestType, ResponseType> { | |||
| requestDeserialize: Deserialize<RequestType>; | |||
| responseDeserialize: Deserialize<ResponseType>; | |||
| originalName?: string; | |||
| requestType: RequestType; | |||
| responseType: ResponseType; | |||
There was a problem hiding this comment.
These type declarations aren't really semantically correct. RequestType and ResponseType are the types of objects that are passed to and received from the gRPC methods. In the case of this library, those are plain objects with a structure matching the declared proto message types, which is why the ServiceDefinition just declares them with object, object.
But requestType and responseType are not that. They are Protobuf.js message descriptor objects that describe the structure of RequestType and ResponseType. @nicolasnoble linked another PR that tried to do this and they declared those values as Protobuf.Type, which I think is the actual correct type.
|
I want to mention that I have the same concerns I had in #378, but I am willing to reconsider. |
|
I am happy to change types when I am back at my desk tomorrow. I am not picky about how the information is exposed, I just need some way to access it. I can update our tooling in order to parse the structure. My main problem is that the information is captured within closures for the serializers and deserializers so I have no way of accessing it without parsing the file twice (once with grpc and once with protobufjs). |
|
@murgatroid99 I have updated the typings to match actual types as suggested. I think I better understand your comment about not exposing protobufjs apis now. Do you have any suggestions as to what you would accept for the requestType and responseType objects? At a minimum, I need information such as field names, field types, and structure (for nested types) in order to create sample request and response objects. |
|
One option, to make it as general as possible, would be to use the JSON representation of the |
|
I am sorry for the long delay here. If you are still interested in this problem, I have proposed a solution at grpc/proposal#116. Please feel free to comment on it. |
|
Thank you for your contribution. This change has been superseded by #703. |
PR for issue #407