Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Decouple ActionCable application logic from low-level logic #27648
This PR is a continuation of the following conversation:
So, here is it)
What has been done:
Client itself still depends on
What's this refactoring for?
This will allow us to completely separate ActionCable public API from low-level sockets manipulations and thus will make it possible to use, for example, different server implementations with ease.
It will also simplify ActionCable channels unit-testing (#27191) and self-testing too.
P.S. "Refactor ActionCable streaming" PR (#27044) can be a part of this process.
maclover7 left a comment
I love the idea behind this PR, and I think this is a really, really good start at separating out some of the concerns with
My fear is that we are introducing too many top-level classes for users to keep track of. If we merge in this PR, then we'll have three:
It's possible we might not need to generate
Thank you again so much for working on this, @palkan!!
Let me clarify: this PR replaces Connection (which is internal) with Client. Which is definitely a bad idea(
We need a better name for "internal" entity and use "Connection" for the "public" one (Client).
What about "Socket"? Connection remains the same from the API point of view, Socket is a layer between raw WebSocket and public Connection.
Done! Now it's backward-compatible.
I would be glad to revisit them too; and propose even more PRs later) I think, major release is a great chance to revisit the whole framework, to discuss its weak or missing parts and fix them.