On Thu, Jul 21, 2022 at 1:07 PM, Eryu Xia <e...@google.com> wrote: > Thanks for the question! I'm a member of the grpc-web team and some > thoughts inline. > > On Monday, July 11, 2022 at 10:02:38 PM UTC-7 steve...@gmail.com wrote: > >> The problem: I would like to not rely on the Envoy proxy for other >> languages like python and rust. >> >> Has there been a discussion of putting on the roadmap a c client and >> server library that would be a GRPC-Web proxy library? Then a client or >> server implementation could integrate middleware to <LanguageX> GRPC Client >> <In-process Proxy--> GRPC-Web --> GRPC-Web Server and GRPC-Web Client --> >> GRPC-Web Server <In-process Proxy--> GRPC Server. > > > RE: Client library -- grpc-web protocol is really designed to be used on > the Web (designed specifically > <https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md> around the > restrictions on Web), so i don't really think it makes sense for it to be > used as a in-process proxy to communicate with a grpc-web server. For that > purpose, using dedicated gRPC language libraries would be a better fix. >
Maybe it's not clear but imagine this developer scenario. I want to develop a gRPC service in python (language of choice) and get started right away developing for the web with hotreloading. Imagine I can get my boiler plate and start developing. VS having to also setup Envoy or gRPC-web Go proxy and integrate it into my build setup. For a dev that's a lot more overhead. The part that I was imagining if there was a standalone C library as GRPC-Web inprocess proxy maybe extracted from Envoy or gRPC-web Go, then you could easily add it to python (or language of choice) by simply using the translation library VS implementing it from scratch for each language, which would also decrease the number of bugs from having separate implementations. RE: Server library -- Sorry there hasn't been any plan for a standalone C > library as gRPC-Web in-proces Proxy. There are several proxy options > currently and can can be found here > <https://github.com/grpc/grpc-web#proxy-interoperability>. > > >> >> The hope would be that a common code base with an interoperability test >> suite, would be able to unlock the capability and adoption for many >> languages. >> > > As mentioned above, I don't think the current plan is to generalize > gRPC-Web protocol to be used for many languages, other than just the Web. > > >> >> Optionally if architected the right way could handle also managing a >> Non-Binary >> Message Encoding ideally JSON which might unlock the interoperability with >> other rest ecosystem tooling which would be desirable for some use-cases. >> > > This is an interesting thought and good input (personally). Appreciate the > ideas :) > > >> >> If you have a reference to any discussions I would be interested in that. >> >> >> >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "grpc.io" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/ > grpc-io/8LRr1qwcWR0/unsubscribe. > To unsubscribe from this group and all its topics, 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/bfbe53ec-d64f-437b-b300-d0a0d0512117n%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/bfbe53ec-d64f-437b-b300-d0a0d0512117n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAPxhEGfxbmdBxQJk1%2Bak367nu3MWZotRZoay11xFkLvR4cZvVg%40mail.gmail.com.
