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/633887e6-cf93-4e0d-aff3-2d1b9bf49c64n%40googlegroups.com.
