Enable RFC6455 (websockets) for streaming endpoints

[tmc]

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.

[joeblew99]

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.

[tmc]

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

[joeblew99]

@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.

[yugui]

I'm happy to accept streaming support with websockets, but I expect two things in the support.

1. Concrete use cases
   • The main reason why I have not yet implemented it was that I didn't have a concrete use case.
2. Good support in client-code generation.
   • At least, we need to be able to expect that we can have a good support in future.

[tmc]

@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.

[shaxbee]

@tmc Your code was extremely helpful! I had slightly different requirements and couldn't use gorilla. Shameless plug: https://github.com/shaxbee/go-wsproxy ;-)

[shaxbee]

@yugui Currently websocket wrapper is used in application I work on to handle user chat and data changes notifications.

[tmc]

FWIW I separated that code: https://github.com/tmc/grpc-websocket-proxy

[yugui]

@tmc Wow. That's excellent. It does not force users to depend on WebSockets but brings even more functionality.

[mikeatlas]

@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

[joeblew99]

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.

[xor-gate]

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?

[rushtehrani]

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?

[johanbrandhorst]

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.

[d-fal]

Any updates on implementing @tmc's wrapper around grpc-gateway ?

[HudsonAfonso]

any updates?

[johanbrandhorst]

This will likely never be merged to the gateway directly, but you can still use the wrapper I believe.