Closed gr8bit closed 4 years ago
Compression should be handled by gorilla/websocket
library we use for WebSocket but they still have an "experimental" label for it (see here). That's why we do not enable it.
We can add an option to enable it via configuration. And you can use it at your own risk 🙂
are there any plans on supporting compression?
We have plans to support compression at a different level by allowing msgpack and other probably other binary formats in the future.
Nice, thanks for the information! I'd love to be able to enable compression via option. 👍
We're using Google's Protocol Buffers on the data layer which already is a binary (and very optimized) format as you will know, but as we transfer many strings and otherwise recurring data it would still pay off to have per message compression in place.
Thank you!
Disclaimer: I'm just getting into WebSocket and stuff.
I'm just experimenting on replacing our project's current "HTTP via Rails plus WebSocket via JS/Socket.io"-APIs with ActionCable/WebSockets completely. Performance is quite important, therefore I came across AnyCable quite early. As we're often sending data packets of several kilobytes to the client via HTTP, we had automatic gzip/deflate in place through a proxy.
But what if we wanted to send these big responses over WebSocket? I found there's a, IETF proposal "permessage deflate" which handles compression if the clients support it (which I can ensure, we're building the client ourselves). As far as I understood, it's a feature on the WebSocket level - something anycable-go handles. As I couldn't find "deflate" in this repo's source: are there any plans on supporting compression?