Grpc-java: Built-in support of grpc-web clients

Created on 5 Sep 2018 · 7Comments · Source: grpc/grpc-java

Supporting grpc-web clients is possible only through a reverse proxy like Envoy which might reduce the performance. Is it possible to add direct support as this wrapper for grpc-go?

Source

lbensaad

👍9

Most helpful comment

In my company, we have a Java Eclipse desktop application (Eclipse RCP) which can be remote controlled by a GRPC API.
Now we want to add a Browser-UI,
Having a proxy would increase the complexity a lot, as this is only an optional feature (but requested strongly by some users).
Please make this possible.

frankbenoit on 20 Feb 2019

👍2

All 7 comments

@lbensaad is performance your only concern for this request? Have you run into any such issues?
Do you have other reasons why you would like this natively?

hsaliak on 6 Sep 2018

@hsaliak, performance is the main reason, another reason is management, a standalone gateway or proxy is an extra headache to me because i need to install it, manage it and maintain it.

lbensaad on 6 Sep 2018

👍2

A side note, the in progress project running gprc server as a servlet may support grpc-web client.

dapengzhang0 on 6 Sep 2018

Performance shouldn't be of concern, but definitely ease of deployment and testing. I'd love not to have to deploy a proxy just to test a web app. Embedded in the app over the same port or another port would absolutely simplify deployment, and would probably be a one-line code as from a user perspective. Again, simplicity is the goal here

simplesteph on 25 Oct 2018

We only have a small web-frontend for which we want to avoid hosting a standalone proxy. Would a small wrapper like the one linked by @lbensaad be also possible/sufficient for the java server? I'd love to take a stab at implementing the grpc-web support but am not sure if its too much for a first contribution.

georgwastaken on 8 Nov 2018

@bnczk It almost certainly is too bug (but I won't stop you!) I was considering doing this as an experiment too, but wanted to go through the designs first. The big thing I see as a problem is making this secure by default. This means handling CORS and XSRF tokens, which I see as API complexity. It is not safe to not tackle those two issues, so they are part of the gRPC-Web design constraints.