Open pontaoski opened 10 months ago
Hi @pontaoski! We've discussed this extensively internally. Websockets are definitely better supported in some environments, but they have their own drawbacks too. We'll have a more detailed proposal (with some pros and cons) up in a few weeks for community discussion.
I'd imagine something like this could be entirely implemented as a middleware? Seems likely it could even be an entirely separate library.
Obviously this depends on what the actual transport codec ends up looking like, but would probably work similar to how gRPC-web works in a traditional gRPC environment.
@mattrobenolt - for sure. Middleware is most attractive if we want this to be an optional add-on that's mostly for browser-to-backend communication. Having it built-in is maybe better (if it's possible with the current interfaces) if we want it to be first-class, even for backend-to-backend communication.
All things to discuss in the proposal!
Is your feature request related to a problem? Please describe. The long incomplete HTTP request/response (and HTTP2 requirement for bidirectional streaming) used by the current streams implementation was already found to be unsuitable for Harmony due to the same issues outlined in the documentation; the streams implementation is blocking us from adopting Buf Connect as a more standard replacement to our home-grown hRPC.
Describe the solution you'd like Support for WebSockets for streams to play nicer with proxies and other standard tooling