Interceptors not called when using new RegisterHandler function

[gpopovic]

Hi guys, I wanted to use new RegisterHandler functions(#947), to get rid of redundant grpc server, but it seems that unary interceptors are not called.

An example, here we have 2 unary server interceptors but they are not used.
https://github.com/hb-go/micro-mesh/blob/5df54724a57a4e4947812d3a8badfd64d6ff5fbc/examples/api/main.go#L101

Without unary interceptors being called, this feature cannot be a drop in replacement.

[johanbrandhorst]

The RegisterHandler method doesn't use gRPC at all, so it would make sense that the gRPC interceptors aren't being called. This is a compromise when using this direct registration.

There's not much we can do here, so I'm going to close it. Please let me know if you want more help.

[rittneje]

@johanbrandhorst Could you not also have a version of RegisterXServer that takes a UnaryServerInterceptor? The interceptor would be called here: https://github.com/hb-go/micro-mesh/blob/5df54724a57a4e4947812d3a8badfd64d6ff5fbc/proto/service.pb.gw.go#L80 I think you have all the pieces you need to properly invoke the server interceptor at this point.

[gpopovic]

@rittneje this is a nice idea

[johanbrandhorst]

I think we should look at the RegisterXServer as separate from the rest of the gateway. It lends itself more to adding HTTP middleware directly to the runtime.ServeMux. I think if you want to buy into the gRPC ecosystem, you probably want to use the other registration methods. gRPC is getting an in-process transport (grpc/grpc-go#906), and that will make the cost of using the gateway that much less. RegisterXServer is still interesting for the usecase where you want to use protobuf for your schema, but don't want to use gRPC for the backend.