grpc-java
grpc-java copied to clipboard
Built-in support of grpc-web clients
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?
@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, 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.
A side note, the in progress project running gprc server as a servlet may support grpc-web client.
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
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.
@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.
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.
I posted a first draft for grpc-web support at https://github.com/EngFlow/grpc-java/tree/grpc-web. I'd welcome any feedback you have, as well as answers to my open questions (in the commit description).
@ejona86, is this something you could take a look at? It would be great if I could start submitting pieces - our internal patch set keeps growing, which makes it harder for us to stay on the latest gRPC releases. Currently looking into XSRF protection.
We want to build a desktop version of our app (using Electron) that uses grpc-web
Of course, we want to get rid of the Envoy first.
The same thing for Rust works just beatifully:
https://github.com/hyperium/tonic/blob/master/tonic-web/README.md
As I can see, it's not so much code in Rust-tonic implementation.
This PR is looking in the same direction, but it's been in review for almost a year: https://github.com/grpc/grpc-java/pull/8596
@ulfjack how do you think, maybe your implementation may be done as a separate package? Not to wait another year.
@visortelle for https://github.com/deephaven/deephaven-core we updated an old patch to support grpc-java in servlets (both javax.servlet and jakarta.servlet are supported), and we added a simple filter that can live on top of the GrpcServlet, and automatically translate grpc-web into grpc so that the servlet can handle it.
The GrpcWebFilter hasn't been merged yet to our main branch, but lives for now in https://github.com/deephaven/deephaven-core/compare/main...niloc132:deephaven-core:grpc-web-servlet-filter until I finalize a few things. Known missing features include support for -Bin
headers and grpc-web-text
content-type. This new class is already licensed as apache2, and once it is merged to main you will be able to obtain it from maven central.
Once https://github.com/grpc/grpc-java/pull/8596 has landed as-is, I intend to propose adding GrpcWebFilter to make it easy for downstream servlet projects to support both grpc and grpc-web. I also have a working patch to add TransportAttr support for mtls (and potentially modernize grpc-netty's support for accessing a javax.security.cert.X509Certificate
instance instead of the deprecated javax.security.cert.X509Certificate
type, plus a few specific quality of life improvements.
Feel free to reach out to me personally for more discussion.