> how it can be achieved directly through implementation on gRPC interfaces?
Nothing offhand that comes to mind. Probably the original code you leveraged is a good starting point. On Monday, August 10, 2020 at 9:40:21 AM UTC-7 [email protected] wrote: > 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, [email protected] 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 [email protected] 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, [email protected] 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 [email protected] >>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/01bd47fc-d46c-416d-b253-44871b6b76bcn%40googlegroups.com.
