Instead of looking for it in Eric's personal repo, you can now find it in the master repository: https://github.com/grpc/grpc-java/blob/master/examples/src/main/java/io/grpc/examples/grpcproxy/GrpcProxy.java
On Sunday, May 7, 2023 at 6:50:04 PM UTC-7 Hakim Kahlouche wrote: > @Eric: I tried to access the service-agnostic grpc proxy link below, but I > am getting 404 (not found): > 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> > > Please let me know if there is a new link for it. > > Thanks > > On Tuesday, 22 January 2019 at 17:30:09 UTC-5 Eric Anderson wrote: > >> I wasn't saying "relay_request" was a "thing". I just used the >> terminology because you used the terminology. >> >> Glad the service-agnostic proxy looks good. I would encourage you to >> consider having a single port and choosing the service-agnostic proxy for >> only certain services; it removes the client from having to know what goes >> where. >> >> On Tue, Jan 15, 2019 at 11:51 PM <[email protected]> wrote: >> >>> @Eric, I did not find any mention of relay_request in the documentation. >>> However, I *loved* the service-agnostic proxy. >>> While reading the code it dawned on me that I can run an instance of >>> this proxy on L, and the client will simply send to port X to get to L, and >>> to port Y to get to R. >>> I'm going to give this a try. >>> >>> Thanks a lot! >>> Dan >>> >>> On Wednesday, January 16, 2019 at 9:13:17 AM UTC+2, [email protected] >>> wrote: >>>> >>>> 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]> 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]. >>>>>> 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/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/f0216e6a-7b05-4f8c-86b4-38b5217ae1cf%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/grpc-io/f0216e6a-7b05-4f8c-86b4-38b5217ae1cf%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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/1685befa-6af6-4cf2-9d80-e27b0ad7eab3n%40googlegroups.com.
