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/6aaef983-f9ce-4aaf-8f6d-2efae523fc80n%40googlegroups.com.
