grpc-swift
grpc-swift copied to clipboard
grpc
Question: Server Reflection Support?
Question Checklist
- [X] Updated grpc-swift to the latest version
- [x] I read the Contribution Guidelines
- [x] I read README
- [x] I searched for existing GitHub issues (especially, there are many resolved issues related to SSL)
Question Subject
Server Reflection Support
Question Description
Is there any plan to support gRPC server reflection?
Not at the moment; this would be nice to have though. Would this be something you'd be interested in working on?
@glbrntt Although it sounds cool, unfortunately I do not have the time for that. :(
@glbrntt The main reason I was asking was because I was trying to use grpcurl with a SwiftGRPC service and not getting much joy.
@glbrntt The main reason I was asking was because I was trying to use grpcurl with a SwiftGRPC service and not getting much joy.
I presume that grpcurl can take your service definitions as a command-line argument; did you try that?
@MrMage yes I did. That at least worked for the list and describe grpcurl features. I never got grpcurl to work calling a method however. My SwiftGRPC based service kept complaining that it couldn't determine the HTTP version.
@MrMage yes I did. That at least worked for the
listanddescribegrpcurlfeatures. I never gotgrpcurlto work calling a method however. My SwiftGRPC based service kept complaining that it couldn't determine the HTTP version.
That sounds like a completely different problem though, which should not be related to reflection.
For future reference:
- The reflection service proto lives here: https://github.com/grpc/grpc-proto/blob/master/grpc/reflection/v1/reflection.proto
- Supporting this would require additional code generation for services to expose the right descriptors
- We'd most likely need to pull this information in from service providers in the request routing handler
We could just encode the original service protobuf message as passed to the compiler into the generated code, then use that to "power" the reflection API at runtime. That would minimize the amount of extra generated code we need.
That being said, I'd say this has fairly low priority.
Agreed, I was just looking out of curiosity as to what this would involve and leaving breadcrumbs...
Would love to get on it as my first Swift project 😄
Since it has a low priority anyway, I don't think I'll be blocking anyone with it.
+1 for making this a priority--it's immensely helpful during debugging.
Not having it makes me want to just use golang instead...
