Decouple ActionCable application logic from low-level logic #27648

palkan · 2017-01-11T16:18:18Z

This PR is a continuation of the following conversation:

Me:

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.

@dhh

I'd welcome refactorings to tease out the socket dynamics from the higher level bits. So do submit a PR on that.

So, here is it)

What has been done:

Connection has been split up into Connection (socket wrapper, low-level) and Client (although I don't like the name, app-level).
Channels code doesn't depend on server/sockets implementation, it only knows about an abstract client .

Client itself still depends on server and its event loop, but also can be isolated.

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

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 ActionCable::Connection. Besides for one concern, this PR looks amazing!

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: Connection, Client, and Channel. IMHO, Client should be "internal" / "low-level / close to the metal" API, and should not be public for users to be interacting with.

It's possible we might not need to generate Connection anymore based on this PR, but that also brings up the issue of backwards compatibility with Rails 5 apps that already have #connect methods (just as an example) declared...

Thank you again so much for working on this, @palkan!!

maclover7 · 2017-01-11T20:16:38Z

actioncable/lib/action_cable/server/configuration.rb

@@ -11,7 +11,7 @@ class Configuration
      def initialize
        @log_tags = []

-        @connection_class = -> { ActionCable::Connection::Base }
+        @connection_class = -> { ActionCable::Client::Base }


Should we keep connection_class around, and introduce a new config option called client_class or similar? Otherwise in ActionCable::Server::Base#call we are declaring an explicit dependency on ActionCable::Connection::Base.

maclover7 · 2017-01-11T20:19:41Z

actioncable/test/client/authorization_test.rb

@@ -5,18 +5,20 @@ class ActionCable::Connection::AuthorizationTest < ActionCable::TestCase
  class Connection < ActionCable::Connection::Base
    attr_reader :websocket

-    def connect


Is there a way to keep this type of code inside of ActionCable::Connection::Base? Otherwise, when, for example, generating a new Rails application we'll have to create three ApplicationCable files: Connection, Client, and Channel...

palkan · 2017-01-12T09:04:24Z

@maclover7

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: Connection, Client, and Channel. IMHO, Client should be "internal" / "low-level / close to the metal" API, and should not be public for users to be interacting with.

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.

maclover7 · 2017-01-12T14:09:26Z

@palkan totally agree. We need to tease out a "public" facing Connection for users to continue to interact with, and have an internal Client / Socket (name obviously isn't super important) class where we hold "raw" / "metal" WebSocket-related details.

palkan · 2017-01-14T18:59:27Z

@maclover7

We need to tease out a "public" facing Connection for users to continue to interact with, and have an internal Client / Socket (name obviously isn't super important) class where we hold "raw" / "metal" WebSocket-related details.

Done! Now it's backward-compatible.

snood1205 · 2017-02-22T20:29:47Z

Is full backwards compatibility ensured?

rafaelfranca · 2017-02-23T04:23:01Z

@matthewd I'm deferring this to after 5.1. If you want to include it, let me know.

palkan · 2017-02-25T10:23:16Z

Is full backwards compatibility ensured?

Integration tests are passed (without any change).

I've also checked my existent apps (e.g. this one I use for Action Cable experiments) – everything works fine.

aried3r · 2018-08-20T12:43:39Z

I just saw that there is some work ongoing for ActionCable regarding testing for Rails 6. I was wondering if some of the other ActionCable PRs by you are also to be revisited for Rails 6?

palkan · 2018-08-20T18:42:34Z

I was wondering if some of the other ActionCable PRs by you are also to be revisited for Rails 6?

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.

rails-bot · 2019-12-18T09:52:42Z

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Thank you for your contributions.

rafaelfranca added this to the 5.1.0 milestone Jan 11, 2017

palkan force-pushed the refactor-action-cable branch from 7d765e5 to 51e2e54 Compare January 11, 2017 16:41

maclover7 suggested changes Jan 11, 2017

View reviewed changes

maclover7 added actioncable needs feedback labels Jan 11, 2017

maclover7 requested a review from matthewd January 11, 2017 20:26

palkan force-pushed the refactor-action-cable branch 2 times, most recently from af59573 to 94df353 Compare January 14, 2017 18:59

TrumpClone mentioned this pull request Feb 22, 2017

Add first draft of release notes for Rails 5.1 🎉 #28096

Merged

rafaelfranca removed this from the 5.1.0 milestone Feb 23, 2017

palkan added 2 commits February 25, 2017 11:08

Extract Client from Connection

d50ba37

Refactor channels to use client instead of connection

c1be162

palkan force-pushed the refactor-action-cable branch from 94df353 to 76bf81f Compare February 25, 2017 10:19

palkan force-pushed the refactor-action-cable branch 4 times, most recently from f9ce7fe to da8962d Compare February 25, 2017 16:00

palkan added 2 commits February 26, 2017 14:19

Rename Connection to Socket and Client to Connection

d035926

Deprecate usage of "Connection#connection_identifier"

d1c330d

palkan force-pushed the refactor-action-cable branch from da8962d to d1c330d Compare February 26, 2017 11:20

palkan mentioned this pull request Mar 18, 2019

Implement ActionCable with Async #35657

Closed

rails-bot bot added the stale label Dec 18, 2019

rails-bot bot closed this Dec 25, 2019

palkan mentioned this pull request Jun 23, 2022

Action cable command callbacks testing #45445

Open

palkan mentioned this pull request Feb 6, 2024

Action Cable server adapterization #50979

Open

5 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Decouple ActionCable application logic from low-level logic #27648

Decouple ActionCable application logic from low-level logic #27648

palkan commented Jan 11, 2017

maclover7 left a comment

maclover7 Jan 11, 2017

maclover7 Jan 11, 2017

palkan commented Jan 12, 2017

maclover7 commented Jan 12, 2017

palkan commented Jan 14, 2017

snood1205 commented Feb 22, 2017

rafaelfranca commented Feb 23, 2017

palkan commented Feb 25, 2017

aried3r commented Aug 20, 2018

palkan commented Aug 20, 2018

rails-bot bot commented Dec 18, 2019

Decouple ActionCable application logic from low-level logic #27648

Decouple ActionCable application logic from low-level logic #27648

Conversation

palkan commented Jan 11, 2017

maclover7 left a comment

Choose a reason for hiding this comment

maclover7 Jan 11, 2017

Choose a reason for hiding this comment

maclover7 Jan 11, 2017

Choose a reason for hiding this comment

palkan commented Jan 12, 2017

maclover7 commented Jan 12, 2017

palkan commented Jan 14, 2017

snood1205 commented Feb 22, 2017

rafaelfranca commented Feb 23, 2017

palkan commented Feb 25, 2017

aried3r commented Aug 20, 2018

palkan commented Aug 20, 2018

rails-bot bot commented Dec 18, 2019