GRPC-Web In-process Proxies (client / server) c library? Possibly Non-Binary Message Encoding (JSON)

Steve Morin

unread,

Jul 12, 2022, 1:02:38 AM7/12/22

to grpc.io

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.

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.

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.

If you have a reference to any discussions I would be interested in that.

Eryu Xia

unread,

Jul 21, 2022, 4:07:42 PM7/21/22

to grpc.io

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 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.

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.

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 :)

Steve Morin

unread,

Jul 21, 2022, 5:03:26 PM7/21/22

to Eryu Xia, grpc.io

On Thu, Jul 21, 2022 at 1:07 PM, Eryu Xia <er...@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 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.

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+unsubscribe@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.

Craig Tiller

unread,

Jul 21, 2022, 5:28:49 PM7/21/22

to Steve Morin, Eryu Xia, grpc.io

It's definitely a use case that makes sense, and I've seen a few cases here at Google where it would make sense for us too - my thought has been to create a gRPC transport in core that could understand the gRPC-Web protocol. It'd be a large amount of work, and I can't see a way that we'd be ready to do it in the short term, but I agree there are benefits if we did so.

To unsubscribe from this group and all its topics, send an email to grpc-io+u...@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.

--
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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAPxhEGfxbmdBxQJk1%2Bak367nu3MWZotRZoay11xFkLvR4cZvVg%40mail.gmail.com.

Steve Morin

unread,

Jul 21, 2022, 8:16:01 PM7/21/22

to Craig Tiller, Eryu Xia, grpc.io

Hope it ends up happening

Steve Morin | Entrepreneur, Engineering Leader, Startup Advisor

Editor at | https://productivegrowth.substack.com/

twitter.com/SteveMorin | stevemorin.com

Live the dream start a startup. Make the world ... a better place.

Sent via Superhuman iOS

Reply all

Reply to author

Forward