- Action Cable built-in server is a great feature: “out-of-the-box” == “developer happiness”. That’s why we use Rails, don’t we?
That’s why I’m trying (as the author of AnyCable) to develop a transparent replacement for Action Cable server, only for production use, especially high-load.
So, I don’t think we should extract the Action Cable server from the framework.
But, as for me, we should think about decoupling application logic from low-level logic. There are some places in the codebase, where we mix application level logic with socket level logic – the Connection class, for example. It would be great to extract its public API (that we use in ApplicationCable::Connection).
Another example is the explicit usage of the server’s event loop in channels.
That’s why I have to patch these classes in AnyCable. But it would be better to avoid monkey-patching in favor of adapter-like implementation.
Btw, I’ve received a lot of requests to support AnyCable for non-Rails applications (yep, sounds a little bit strange) and I’m going to implement smth like Action Cable Lite – no Rails, no server, just application logic (channels, streams). Maybe, that could be a starting point to refactor the Action Cable.
- I’ve repeated WebSocket Shootout for many times, but I haven’t seen Action Cable crashing. It eats a lot of memory; it can be slow for broadcasting (when more than 1k connections per stream).
But it works.
AnyCable looks lovely and it’ll be interesting to follow the new Rack specification. But Action Cable should work out-of-the-box with no additional servers or setups required beyond Puma. If there are options available that fulfill that criteria and are drop-in replacements, awesome, let’s look at that. Also happy to accommodate whatever AnyCable might need, but haven’t seen any requests.
Btw, there is an issue (https://github.com/rails/rails/issues/26999) with some proposals.
The most problematic feature (from the AnyCable point of view or other adapters, if any) – custom streaming callbacks. I’d like them to be deprecated)
Why? First, because they affect performance: straightforward broadcasting is much more efficient (=faster). And, secondly, IMO, it breaks the concept of broadcasting itself – we’re not simply re-transmitting messages to all clients, but we can do anything in the middle, different clients may receive different messages – should we have used different streams instead?
Do you use custom callbacks in Basecamp?