Hi. Thanks for sharing the information regarding Envoy proxy. I think it will require a lot of changes for me to integrate Envoy proxy in our architecture and writing a simple reverse proxy (if it works) the way I described above is an easier, faster and better option. Do you have any feedback on how it can be achieved directly through implementation on gRPC interfaces?
On Sunday, 9 August 2020 19:09:54 UTC-7, sanjay...@google.com wrote: > > Envoy proxy uses xDS to dynamically change the routing configuration - > some of these can be header matching rules that encapsulate your dynamic > logic. This of course requires an "xDS" server to supply the route (and > other dependent) configuration. > > In gRPC too there is support for xDS on the client side and very soon > there will be support for header based routing as described here > <https://github.com/grpc/proposal/blob/master/A28-xds-traffic-splitting-and-routing.md#routing-lb-policy> > which > means the client itself does the header based routing. But this too > requires putting your logic in an xDS server similar to above (once the > feature is available in gRPC Java). > > On Sunday, August 9, 2020 at 6:28:29 PM UTC-7 chetan...@gmail.com wrote: > >> I did look at Envoy proxy. The business logic to redirect traffic is >> dynamic and involves fetching latest information from another distributed >> system and I couldn't find a straight forward way to do it using Envoy >> proxy. >> My requirement to direct traffic is not static or deterministic, hence >> building a custom solution seems a better option. >> >> >> On Sunday, 9 August 2020 18:17:51 UTC-7, sanjay...@google.com wrote: >>> >>> Have you considered using the Envoy proxy >>> <https://www.envoyproxy.io/docs/envoy/latest/intro/intro>with static >>> configuration so you don't need to develop a reverse proxy of your own? >>> >>> On Thursday, August 6, 2020 at 1:47:52 PM UTC-7 chetan...@gmail.com >>> wrote: >>> >>>> Hi >>>> >>>> I am planning to build a grpc-reverse proxy that sits in fronts of a >>>> few of our grpc services. >>>> >>>> *Requirement:* >>>> We have a client A that at the moment talks to B or C (based on >>>> internal logic). We want to move this logic to the proxy layer. >>>> So we will introduce a new grpc-reverse-proxy server P sitting in front >>>> of B and C and redirect requests based on the headers passed and the >>>> application logic. Below is how I'm thinking of designing it- >>>> >>>> A (starts calls to P with custom headers ) >>>> -> P >>>> - Implements ServerCallHandler to read headers and run >>>> application logic >>>> - Has 2 channel objects that it uses to connect to B & C as a >>>> client >>>> - Based on the logic proxies the request to either B or C >>>> -> B or C >>>> - Processes the request and returns the response back to P >>>> -> P >>>> - Proxies the response back to A >>>> >>>> >>>> I have leveraged some of the code from here - >>>> https://github.com/ejona86/grpc-java/commit/29728aeb003ced3c190197c176563643be22bef1, >>>> >>>> to build the logic described above and it works. >>>> >>>> I couldn't find a lot of documentation on how the client and server in >>>> gRPC internally talk to each other and what are the best practices when >>>> writing your own ServerCallHandler, ClientCall.Listener and >>>> ServerCall.Listener; particularly a sequence diagram of how startCall(), >>>> onMessage(), onHalfClose(), onCancel() and onReady() are called and what >>>> are the guarantees gRPC provides. >>>> >>>> I would like to know if my approach to tackle the requirement sounds >>>> acceptable and whether there are things that I should take into >>>> consideration when building this solution. One thing for example is that >>>> the clients will have to create a new stub for each request to add custom >>>> headers before starting a call. Is this good or bad? I don't see any >>>> problem with it in terms of how gRPC works but would like to know if it >>>> will break something I'm not aware about. >>>> >>>> Thanks >>>> Chetan >>>> >>> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/e6e1238e-6e0f-4cba-b09e-7543878bd5a8o%40googlegroups.com.
