Any Cables Monthly #5
Winter is coming ☃️Take a look at this last autumn leaves we collected in November!
Highlights
A long-awaiting feature/fix for Action Cable, especially for those running their apps on Fly.io: Action Cable now can survive Redis connection failure without crashing the server process or disconnected all the clients.
You can use the fix today with any Rails version via the action-cable-redis-backport gem.
This release brings two cool new features: hotkeys support for actions and Outlets API. The latter allows you to build molecules out of atomic controllers.
Articles
AnyCable: Render deployment guide
Learn how to deploy AnyCable on Render! (Easy-peasy comparing to our Heroku guide 😄)
Releases
This minor release brings two features: cookies filtering (reducing RPC payloads) and verified Redis TLS connections support. In addition, anycable gem v1.2.5 and anycable-go PRO v1.2.2 were released with the corresponding changes.
Stimulizer provides convenience methods for working with StimulusJS in views, templates, and view components. New to view components? Check out the View Components in the Wild blog series.
Frame of curiosity: Decompressing compression
Sending larges amount of data over WebSockets is getting more and more common with the growing popularity of HTML-over-WebSockets frameworks, such as Hotwire and StimulusReflex. Traffic (and bandwidth) is also a vital resource that we should take care of. Can we optimize HTML payloads to reduce the number of bytes sent by a server?
For regular HTTP requests, we solve this problem by adding compression (gzip, Brotli). (Usually, CDNs do that for us these days). What about WebSockets?
The permessage-deflate extension has been around for more than 8 years (though wasn’t fully supported by major browsers until recently). It allows compressing WebSocket frames using popular algorithms (such as gzip) and defines a protocol for clients and servers to negotiate the compression parameters.
This article gives an excellent overview of this feature as well as the tradeoffs of using compression. Tl;dr Compression comes at a price and affects both CPU and RAM usage (proportionally to the number of connections). That’s why it is usually disabled by default in WebSocket servers (in AnyCable-Go, you can opt-in by adding the --enable_ws_compression).
In the case of structured JSON payloads, using Msgpack or Protobuf could be more beneficial (and independent of the client-side support and tweaks). But what about HTML? In theory, Hotwire/StimulusReflex apps should benefit from enabling permessage-deflate, but wouldn’t be this benefit offset by the increased server resources usage?
I haven’t tried to perform such tests (I know there are some research attempts in this direction).
I believe that the LiveView approach(not sending full HTML) is the way to go, not something more generic (like compression). What do you think?