Whats the difference between https://github.com/grpc/grpc-web and this?
I鈥檇 like to know also if it鈥檇 be smart to not duplicate efforts but have all of us develop the grpc/grpc-web project.
There's quite a long and illustrious history between the two projects, but basically it comes down to slightly different design decisions at the start of the project.
This project uses TypeScript and the npm ecosystem to implement and publish an npm module that can be used with other projects. The backend proxy is written in Go, which is an accessible language to most developers. It's easy to deploy and super easy to integrate with existing Go gRPC servers.
The grpc/grpc-web project was started internally at Google at about the same time as this was, and they chose to build their project on the Google Closure Compiler base. Their backend proxy was originally implemented as a C++ NGINX module, but recently has been released also as an Envoy plugin. Very recently they've considered releasing the library as an npm module as well.
I encourage you to read Improbable's blog post announcing the project but as a summary:
improbable-eng/grpc-web:
grpc-web-clientgrpc/grpc-web:
All of this is further complicated by the fact that even though both sides agree on a spec, apparently neither of the clients is compatible with the others proxy.
Personally, I've used the Improbable library and extensively, and I can't see it not being a future proof way of consuming grpc-web, as I expect both clients and proxies to converge on a single compatible protocol long term.
Wohoo https://github.com/improbable-eng/grpc-web/issues/162#issuecomment-410437028 馃帄
So does this mean they both use the same protocol now or that its different but they now have support for this lib's protocol?
I don't know how or why they were incompatible, but it seems at least gRPC/gRPC-Web has tested their client against this proxy. It still only supports unary calls but it's a step in the right direction. I think it should make users more confident that they can choose to use this repos client and proxy now (for bidi streaming for example) and be able to change to the official client later.
This issue is more a matter of documentation, so I will leave it open for anyone to add my comments (or their own) to the README.
I'm new to gRPC; if I understand this thread properly does this mean that improbable's version of gRPC-web does not work with Envoy? does the improbable go proxy scale? Does is cluster? does it provide a single endpoint for the client to connect to or do you need to run a proxy per service?
My goal is to use web components on the front end that match up to gRPC based micro services on the backend so that we basically have microservices on both the front and back, Im trying to sort out how to get everyone talking to each other.
Sounds like you should evaluate both this and the official client and proxy to see what works for you. See my other comments in this issue for more information.
Just to follow up, I've done some preliminary testing of the Improbable and grpc-web clients in https://github.com/johanbrandhorst/grpc-web-compatibility-test and for simple use cases both are compatible with each other. For things like bidirectional streaming or application/grpc-web+text there are some incompatibilities though. More information will be forthcoming.
I'll bump this thread when it's ready :)
But idk if this isn't already fixed with grpc_proxy of nginx.
I can confirm the nginx grpc_proxy implementation does not come with grpc-web support. Here's the nginx work item for grpc-web support: https://trac.nginx.org/nginx/ticket/1536
I'm pleased to finally be able to share my blog post on grpc-web: https://grpc.io/blog/state-of-grpc-web. I hope that should cover most of the questions.
grpc/grpc-web is going to support Bidi streaming, Typescript/Angular and Websocket, Proxy, Non-Binary Message Encoding, Non-Closure compiler support as well
Check it out : https://github.com/grpc/grpc-web/blob/master/ROADMAP.md
Seems like Official grpc/grpc-web project is more "Official" and more powerful in nature.
I am just a newbie of grpc world, and wanna know which side I should dig in first ?Can I use both of them and switch between them depending on my circumstance?
grpc/grpc-web is going to support Bidi streaming, Typescript/Angular and Websocket, Proxy, Non-Binary Message Encoding, Non-Closure compiler support as well
Check it out : https://github.com/grpc/grpc-web/blob/master/ROADMAP.md
Seems like Official grpc/grpc-web project is more "Official" and more powerful in nature.I am just a newbie of grpc world, and wanna know which side I should dig in first ?Can I use both of them and switch between them depending on my circumstance?
Looks like grpc/grpc-web folks are working on it slowly...
I may support this project more than that. !
Keep it up men! 馃憤
We've used this project for a few internal projects and evaluated it vs grpc/grpc-web for a major public project. One of our requirements is server side rendering and the configurable transport of this project allowed us to do that.
For reference grpc/grpc-web does not look to support server side rendering https://github.com/grpc/grpc-web/issues/453#issuecomment-460414940
Can I use wrapped server to handle grpc requests from backend clients written in go ?
Because my test golang clients stated to return nil, when I use wrapped grpc server.
Guess I need to use proxy, if I want to handle backend and frontend grpc requests.
@lostsequence you can support both gRPC-Web and gRPC requests on the same port, yes.
@lostsequence you can support both gRPC-Web and gRPC requests on the same port, yes.
And to do that I should use proxy, because if I will use grpcweb.WrapServer() and http.Server it will handle only gRPC-Web requests. I understood correctly?
No, you can keep using grpcweb.WrapServer, but you need a traffic splitting handler: https://github.com/johanbrandhorst/grpcweb-example/blob/adfc1a47f9f002b1fd84eeec810af3ba3cac7473/main.go#L123
This blog post summarise it well: https://grpc.io/blog/state-of-grpc-web/
Going to close as it has been a long time and I'm not sure if this is relevant anymore.
Most helpful comment
There's quite a long and illustrious history between the two projects, but basically it comes down to slightly different design decisions at the start of the project.
This project uses TypeScript and the npm ecosystem to implement and publish an npm module that can be used with other projects. The backend proxy is written in Go, which is an accessible language to most developers. It's easy to deploy and super easy to integrate with existing Go gRPC servers.
The grpc/grpc-web project was started internally at Google at about the same time as this was, and they chose to build their project on the Google Closure Compiler base. Their backend proxy was originally implemented as a C++ NGINX module, but recently has been released also as an Envoy plugin. Very recently they've considered releasing the library as an npm module as well.
I encourage you to read Improbable's blog post announcing the project but as a summary:
improbable-eng/grpc-web:grpc-web-clientgrpc/grpc-web:All of this is further complicated by the fact that even though both sides agree on a spec, apparently neither of the clients is compatible with the others proxy.
Personally, I've used the Improbable library and extensively, and I can't see it not being a future proof way of consuming grpc-web, as I expect both clients and proxies to converge on a single compatible protocol long term.