grpc-ecosystem
Enable RFC6455 (websockets) for streaming endpoints
The most reliable way to support streaming (including bidi) to web clients is RFC6455 websockets. Go has a rich implementation for websockets and grpc-gateway should enable grpc streaming endpoints with it.
I notices that the swaggger and openAPi group as thinking of supporting WS as part of the swagger spec.
I am currently using GRPC internally, and wrapping with the GRPC gateway, to produce a swagger spec for the outside world. then from the swagger spec i generate Javascript API.
So, if swagger starts to offer WS, then things will be complete.
preliminary work and kind of hacked up but https://github.com/tmc/grpcutils/blob/master/websocket_proxy.go is an example of wrapping grpc-gateway with a transparent websocket upgrade
@tmv Thank you for pointing that out. This is really something i have been wanting for a while.
The code i saw referring to it was in the go-swagger repo. They are these days part of the open-api initiative. I cant remember the exact file. But i tried that stack, and now am trying our the GRPC, GRPC-Gateway stack. I feel this is better for many reasons we dont need to go into.
Also i am building a React and React native stack on top of all this and saw your code for generating thats part of the stack at https://github.com/pwmckenna/swagger-models-to-react-proptypes. This is awesome work, and something on my critical path.
I'm happy to accept streaming support with websockets, but I expect two things in the support.
- Concrete use cases
- The main reason why I have not yet implemented it was that I didn't have a concrete use case.
- Good support in client-code generation.
- At least, we need to be able to expect that we can have a good support in future.
@yugui I think there's a basic argument of just fully expressing grpc's semantics to browser clients.
I have starts of basic implementations of flowtype and elmlang generators here https://github.com/tmc/grpcutils and first-class streaming support in grpc-gateway will only motivate more effort in this area.
@tmc Your code was extremely helpful! I had slightly different requirements and couldn't use gorilla. Shameless plug: https://github.com/shaxbee/go-wsproxy ;-)
@yugui Currently websocket wrapper is used in application I work on to handle user chat and data changes notifications.
@tmc Wow. That's excellent. It does not force users to depend on WebSockets but brings even more functionality.
@tmc Great job on that mux wrapper. I was looking for a good example for wrapping gRPC-proxy endpoint with Throttler, but also needed WebSocket extension of streaming endpoints anyways. Double win! Would like to see this pulled into the main project, +1 @yugui
I would also like to see this pulled into the main project. Especially with the genproto work being done.
It would solve lots of boilerplate hacks for me and probably others.
I like the implementation of @tmc. Seems the issue has not got any updates in some time. Are you still open to pull it into the project?
Is there a plan to pull @tmc's implementation into upstream or is there another way to support streaming for web clients that I'm not aware of?
This hasn't been looked at in a while, but it should still be usable as a third party wrapper if you want to use websockets for bi-directional communications. Note that you can already do client side and server side streaming with vanilla grpc-gateway. What are you trying to do? Maybe join #grpc-gateway on gophers slack and we can discuss.
