Support Reflection

[autodidaddict]

trafficstars

Supporting reflection would allow service developers to test and experiment using tools like grpcurl. Other SDKs contain the the ability to register the reflection service ... is there a timeline for this or is anyone actively working on it?

[siddontang]

Hi @autodidaddict

We have no plan for this now, but this is a cool suggestion.

Can you give us some ideas about what needs to do if we support this feature?

[autodidaddict]

Reflection is supported in the Go and .NET SDKs for gRPC, I'm not sure about the other SDKs since I don't use them. But it's fairly straightforward - they provide an implementation of the reflection service PROTO and then provide some way for developers to host this reflection service alongside their actual service on the same port. With this in place, we can use tools like grpcurl to query, identify, and obtain metadata on our services. Having this reflection ability makes our services far more tooling-friendly, which in turn lowers the barrier to resistance of gRPC over something like REST.

The reflection service is basically just this:

service ServerReflection { 
  rpc ServerReflectionInfo(stream ServerReflectionRequest)
      returns (stream ServerReflectionResponse);
}

If you look at the other SDK implementations, you'll see that they basically just do a switch on the request type and return the appropriate data. In the .NET implementation, there is a descriptor generated into the gRPC C# file which provides access to metadata and the original proto IDL, and these descriptors are then passed to the reflection service implementation that comes with the SDK.

Here is a link to the .NET service implementation of Reflection.

Here is where the Go SDK implements reflection.

[autodidaddict]

Here's a list of the operations that a client can request of a reflection service (you'll see this as an enum in the Reflection proto):

• Ask for a proto file by filename
• Find a proto file that contains the supplied fully-qualified symbol name
• Find a proto file that defines an extension that extends the given message type with the given field number
• Find the tag numbers used by all known extensions of a message type
• List the names of registered services

Some SDKs return StatusCode::NOTIMPLEMENTED for some of these (.NET doesn't implement "file containing extension" and "all extensions" request types)

[autodidaddict]

TL;DR - if the service implementation has access to a map of filename->proto IDL, then it can support the bare minimum reflection functionality