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/7ab76545-324b-4a4d-9858-b3b752291a8do%40googlegroups.com.
