ardatan/graphql-mesh

Reflection Header grpc-reflection-js

mbazos opened this issue · 3 comments

I am working with the graphql-mesh gRPC input handler and specifically with the gRPC reflection API as to get the protos dynamically from the gRPC service. My question is that we have several gRPC services and the reflection API requires to listen on the root path.

We use tools like grpcurl which have an option for a -reflect-header and then our infrastructure knows when it sees that header to route that request to a specific gRPC service. Here is an example of grpcurl using the -reflect-header:

grpcurl -reflect-header grpc-service:proto.MyGrpcService -d '{"name":  "mike"}' localhost:9090 proto.MyGrpcService/hello

My question is:

I am not sure if to accomplish this the underlying library grpc-reflection-js needs to support this first

Opened an issue on grpc-reflection-js
redhoyasa/grpc-reflection-js#8

Hi, I'd like to know more about the reflect-header. From my understanding,reflect-header will be added to gRPC metadata but used only on reflection request. Is that correct?

@redhoyasa Yes this would only be for the reflection request. If you can please take a look at this utility https://github.com/fullstorydev/grpcurl

From the help:

  -reflect-header value
    	Additional reflection headers in 'name: value' format. May specify more
    	than one via multiple flags. These headers will *only* be used during
    	reflection requests and will be excluded when invoking the requested RPC
    	method.

The main reason for this is depending on your infrastructure/routing the reflection API needs to be on the root of the service and if you have more than one gRPC service routed through the same gateway the reflection request wouldn't know the right underlying service to hit.

For example given the two grpc services:
https://sample-gateway/grpc-service-one
https://sample-gateway/grpc-service-two

imagine sample-gateway could be ngnix or istio proxy. If you make a grpc call to https://sample-gateway/grpc-service-one it works fine, but if you do the reflection request it expects the call to be made on https://sample-gateway/ which then ngix/istio or some other proxy would need to identify the reflection request and route it to the proper underlying grpc service.

Reading the gRPC reflection spec, the reflection API should always be served on the root so this isn't something that's configurable or should be modified. I believe this is the reason grpcurl added reflect-header to specifically satisfy this requirement.