Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stalled project? #189

Closed
ravihugo opened this issue May 29, 2018 · 12 comments
Closed

Stalled project? #189

ravihugo opened this issue May 29, 2018 · 12 comments

Comments

@ravihugo
Copy link

ravihugo commented May 29, 2018

I'm not trying to throw shade, but... obviously a lot of people are being walked through gRPC by google advocates, and this project is extremely key to understanding how to move forward with grpc in websites or simply in phonegap/react-native style apps that use REST still. How shall we migrate away from REST when so many items seem to be hinged up on this project that isn't really moving forward?

@stanley-cheung
Copy link
Collaborator

Sorry for the delay. Are there specific features that your use case is waiting on? We are working on some of the features we set out in the spec. For example, we will be adding support to suppress CORS preflight requests shortly. (Second bullet point of https://github.com/grpc/grpc-web/blob/master/PROTOCOL-WEB.md#cors-support) We are also working on Retry support etc.

@ravihugo
Copy link
Author

ravihugo commented May 30, 2018

Thanks for reaching out. I know developing open source is hard. I think part of the issue is that without a good push from Google it can be scary/worrysome not knowing if this is the next big thing beyond REST or if we have to scale back our ambitions.

I think my use-case is generally in need of the following:

  • typescript protoc output.
  • JS streams (without callbacks) would be nice, for example using RX Observables would likely fit the streaming bill nicely.
  • Windows/Mac localhost development model (without docker) - Presumably without running nginx locally or some other web server for local development.

@IanDuncanson
Copy link

I would second the feedback above. I think the reliance on nginx is problematic for us (we deploy on Windows, nginx is slow and not approved for our servers). I think the approach taken by improbable for the proxy is at least a lot more scalable and easier to deploy in multiple environments. And the typescript output is invaluable for front end web development.

@glerchundi
Copy link
Collaborator

Same opinion here.

Additionaly it would be more than interesting to have javascript grpc-web client published as a commonjs module in npm registries.

@johanbrandhorst
Copy link
Collaborator

Nginx as the proxy choice has been a major headache for me as well. Personally I would welcome more of a joint approach with Improbable and ideally move any features of this proxy to theirs and focus development in one place. The fact that two options exists and they basically live in isolation of each other is bad for the community and adoption of either project. Maybe settle on ONE proxy and release rival clients? The proxies are almost identical in functionality already.

@wenbozhu
Copy link
Member

wenbozhu commented Jun 1, 2018

@ravihugo Thanks for the feedback!

TS and better streaming APIs (i.e. besides the Node streams) are on the road-map.

Unlike other languages, grpc-web/JS is being developed internally for Google/Alphabet's own projects first. This limits how quickly we are able to release features for OSS users. At the same time, web ecosystems are prolific in every layer ... E.g. Google closure support is a must, which is used by Google search/gmail/... but not so much externally.

On proxies, our immediate plans are:

  1. Improve Envoy support; and possibly make Envoy the default proxy. grpc-web is already integrated in Envoy, which means there is no custom code to build.
  2. Publish our inter-op tests, and include the Improbable Go proxy as part of the interop test suite. This will ensure the two client libraries will work against different proxies. We have worked closely with Improbable team in the past in defining the gprc-web protocol spec.
  3. Support in-process proxying in more languages (in addition to Go). For this, we are planning to add Python support first, and contributions are always welcome.

===

@glerchundi Could you help file an issue on the npm registry?

@IanDuncanson
Copy link

Making Envoy the default proxy does not help us poor souls who have Windows backends, in fact it makes it impossible

@wenbozhu
Copy link
Member

wenbozhu commented Jun 5, 2018

@IanDuncanson which language are you using for your windows backends?

Seems MS is involved to support Envoy on Windows ... per this Envoy issue.

@wenbozhu
Copy link
Member

wenbozhu commented Jun 5, 2018

Add an Envoy developer just passed me this

https://github.com/Microsoft/envoy

@IanDuncanson
Copy link

@wenbozhu thanks for this link, very interesting. We use mainly C# and C++ on our backend, but our GRPC services are C++. I will try build this up and give it a go.

@glerchundi
Copy link
Collaborator

@glerchundi Could you help file an issue on the npm registry?

@wenbozhu done #197.

@ravihugo
Copy link
Author

ravihugo commented Sep 6, 2018

Blown away by all the updates recently. Going to invest time into this again! Sounds like GA in Oct 👍

loyalpartner pushed a commit to loyalpartner/grpc-web that referenced this issue Sep 4, 2020
Fixed bug where we got unhandled promise rejections in fetch pump
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants