Hey, everyone!
1. 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).
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.
2. 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.
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?