That is half correct ;-) in my scenario L is also a service provider, but it is also a proxy for requests I need to send to R. I was not aware of relay_request. I'll definitely check it out, as well as your service-agnostic example.
Thanks, Dan On Tuesday, January 15, 2019 at 5:57:43 PM UTC+2, Eric Anderson wrote: > > It sounds like L is just a proxy in that case. You use the relay_request > if that feels natural to you. You can also do "L7 load balancing" by > relaying requests at the HTTP/2 or gRPC level. I have made an example > service-agnostic gRPC proxy in Java > <https://github.com/ejona86/grpc-java/blob/grpc-proxy/examples/src/main/java/io/grpc/examples/grpcproxy/GrpcProxy.java>. > > My example proxies everything, but it is possible to also proxy only > services or methods. I think you can do semi-similar things in other > languages, although the difficulty may vary. > > On Mon, Jan 14, 2019 at 11:40 AM 'Carl Mastrangelo' via grpc.io < > [email protected] <javascript:>> wrote: > >> Yes, this is possible. You'll need to implement some unpacking scheme on >> L, but it can then forward the raw bytes of the request. Note that if you >> are using Proto, you may not be able to use all the generated stub code. >> If C, L, and R all know about the same message types, then you can use the >> proto stubs. >> >> Note also that the headers will need to be captured from C->L, and the >> response trailers from R->L. If you wanted this to be "delayed" in any >> way, it may get more tricky. >> >> On Sunday, January 13, 2019 at 12:52:29 AM UTC-8, [email protected] >> wrote: >>> >>> Consider a grpc client C, and servers L & R (local & remote). >>> Servers L & R are connected. Client C can reach only server L. >>> >>> Client C needs to send a request to server R. >>> >>> Can I create a "relay_request" message that server L will support, where >>> the body is the request to send to server R? (also dealing with relaying >>> the reply) >>> >>> Is there anything better I can do for such a scenario? >>> >>> Thanks, >>> Dan >>> >> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/grpc-io. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/grpc-io/fc766ee0-a9b7-46f2-bbd5-024c1fba3e1a%40googlegroups.com >> >> <https://groups.google.com/d/msgid/grpc-io/fc766ee0-a9b7-46f2-bbd5-024c1fba3e1a%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/d9dc771b-6a7b-4495-be4a-b1cd2446c4b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
