gRPC-gateway support

[alexkappa]

Is your feature request related to a problem? Please describe

Relates to #118

With support for gRPC added to patron, I was wondering whether the introduction of gRPC-gateway would be a natural next step.

In their own words:

The grpc-gateway is a plugin of the Google protocol buffers compiler protoc. It reads protobuf service definitions and generates a reverse-proxy server which translates a RESTful HTTP API into gRPC. [...]

This helps you provide your APIs in both gRPC and RESTful style at the same time.

Such plugin would provide certain benefits that may be beneficial to patron. With minimal additions to an existing .proto definition, grpc-gateway can generate http handlers that can proxy the request to our usual grpc service implementations.

syntax = "proto3";
 package your.service.v1;
 option go_package = "github.com/yourorg/yourprotos/gen/go/your/service/v1";
+
+import "google/api/annotations.proto";
+
 message StringMessage {
   string value = 1;
 }

 service YourService {
-  rpc Echo(StringMessage) returns (StringMessage) {}
+  rpc Echo(StringMessage) returns (StringMessage) {
+    option (google.api.http) = {
+      post: "/v1/example/echo"
+      body: "*"
+    };
+  }
 }

Another feature that may be attractive is the generation of swagger/openapi docs from the same .proto definitions.

Describe the solution

If I understand the architecture of Patron well enough, I imagine this would fit in as a Component... Implementation could borrow from the grpc component as well as the http component (after all the gateway is a http.Handler).

I'd be happy to work on this given enough time in the weekend.

Additional context

• Example .proto with all the bells and whistles
• Serving gRPC and HTTP on the same port
• In addition to annotations, configuration is also possible using an external configuration file
• Heath Checking

[mantzas]

Seems like an interesting thing...
There are some things that we have to make sure that they work though...
HTTP has implemented a lot of features which we have to see how to also provide here e.g. caching, media type control, tracing, CORS, etc.
Seems like a very tricky problem to solve...
@tpaschalis @drakos74 what do you think>?

[drakos74]

Seems like an interesting thing...
There are some things that we have to make sure that they work though...
HTTP has implemented a lot of features which we have to see how to also provide here e.g. caching, media type control, tracing, CORS, etc.
Seems like a very tricky problem to solve...
@tpaschalis @drakos74 what do you think>?

@mantzas , i see your point, but it seems worth investigating more. @alexkappa , would you be willing to investigate those points , e.g. how to do in grpc ? (maybe a pre-defined grpc schema template ? ) . It would be a great improvement if we could find a solution to those (that integrates with the HTTP implementation as well).

[alexkappa]

Thanks for the feedback, and apologies for the late reply.

I understand there are some nice goodies available in the framework that would be a pity if we lose.

My hope is that it should be doable assuming these components play well with the http.Handler contract, or the de facto middleware contract.

With your blessing, I’d like to try to send something by when I get the chance and we can discuss it further.

[mantzas]

Thanks for the feedback, and apologies for the late reply.

I understand there are some nice goodies available in the framework that would be a pity if we lose.

My hope is that it should be doable assuming these components play well with the http.Handler contract, or the de facto middleware contract.

With your blessing, I’d like to try to send something by when I get the chance and we can discuss it further.

@alexkappa Of course you should try, was pointing out that there are a lot of things that needs to be considered and to get an understanding of the overall size of this feature. Obviously people are "eating an Elephants bite by bite"... ;)

[mantzas]

Since we are already supporting gRPC and HTTP component it does feel that there is a need for that. We will be closing this issue, but thanks for the suggestion.