Closed metahertz closed 3 years ago
tstromberg
commented
3 years ago Adding a discuss label because I'm not yet sure if this is the right way to go about doing things.
What kind of proxy have you run into that supports REST but not gRPC? GRPC is implemented on top of HTTP/2, so it should traverse any proxy that supports it: https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md
tstromberg
commented
3 years ago We discussed this issue in triage today, and decided that falling back to a HTTP 1.x RPC calls was judged to be an unnecessary complication to our code base that could cause future issues. Closing this for now until more evidence comes in.
In the mean time, I highly recommend upgrading to a proxy that is capable of carrying HTTP/2 traffic.
Hoping to have a discussion here on the best way to support this (or current solutions that i've maybe missed?).
I have a usecase where the tink-server (and hegel) will be a couple of hops away from the tink-workers, via a proxy which supports REST but not gRPC.
After some codebase digging, I noticed that the server components implement grpc-gateway to also expose a REST endpoint, but the client code is gRPC only.
I'm not aware of a project which does the opposite of grpc-gateway (allowing a proto grpc definition to automatically send REST requests instead) so I wanted to ask what would the best way be to implement a REST codepath in the tink-worker, ideally without a load of code duplication and causing a load of extra work for each future developers update.
Expected Behaviour
flag or automated fallback (flag probably cleaner) for tink-worker to try non-grpc communication to tink-server and hegel.
Current Behaviour
Clients only speak gRPC
Possible Solution
Hoping for cleverer people who know the codebase to suggest the best solution, happy to do the work :)
Steps to Reproduce (for bugs)
N/A
Context
as above, I have a usecase where the tink-server (and hegel) will be a couple of hops away from the tink-workers, via a proxy which supports REST but not gRPC.