Action Cable: allow multiple instances of Server::Base with different configs

[palkan]

Context

When trying to create a separate cable instance (e.g. within an engine), we faced a problem of ActionCable::Server::Base relying on the global configuration (i.e. ActionCable::Server::Base.config).

We want our engine to have a separate, isolated, Cable server instance with its own configuration.

See the example app using this patch: https://github.com/palkan/engine-cable-app

Summary

• Add ability to pass a config as a Server.new argument.

Other Information

This problem has been already discussed here: #27425 (comment) (we've adjusted the test from that PR as well).

The related issue not included into this patch (separate PR?): currently, only the Redis adapter supports channels prefixes. With the ability to have engined cables we'll need to isolate streams for all distributed adapters (e.g. postgresql, async/inline adapters do not share anything).

One potential caveat of using multiples cables within the app is the lack of isolation for channel classes, i.e. it is possible to subscribe (or at least try to) to any channel from any connection (see https://github.com/rails/rails/blob/v5.2.2/actioncable/lib/action_cable/connection/subscriptions.rb#L35).

One possible solution is to add config.base_channel_class parameter and use it instead of a ActionCable::Channel::Base (i.e. config.base_channel_class >= subscription_klass).

Another way is to get away from using Ruby class names as identifiers, and build a per-connection registry/map of identifiers->class (like it's done in https://github.com/palkan/litecable).

P.S. Thanks to @composerinteralia for pairing with me on this feature.

[jeremy]

Cool, @palkan. Could you share the motivation/pressures behind running a separate cable server in the engine, vs using a single server and providing channels within the engine?

[palkan]

Could you share the motivation/pressures behind running a separate cable server in the engine, vs using a single server and providing channels within the engine?

Separate cable server allows you to:

• use a different set of identifiers
• use a different authentication strategy (we perform authentication within a Connection class and authorization within a Channel class).

My particular use-case is the following: I'm building a Admin Console engine for the app, I'd like to add real-time functionality in the future, but I don't want to worry about whether the main app has its own cable, will there be any conflicts, etc..

So, I want an isolated, plug-n-play, way to add real-time functionality to the app: just drop a gem and that's it.

[rmacklin]

So, I want an isolated, plug-n-play, way to add real-time functionality to the app: just drop a gem and that's it.

That's an interesting idea! Would be interested in hearing how it turns out.

[palkan]

@kaspth could you please put this one on your list too?)

[kaspth]

Looks good! We'll just need a changelog entry and then squash your commits to 1, thanks!

[palkan]

@kaspth Done! 🙂

[palkan]

@kaspth Just a friendly reminder) Rebased and ready to be merged

[shinespark]

On Wed, Feb 13, 2019 at 7:22 Vladimir Dementyev ***@***.***> wrote: @kaspth <https://github.com/kaspth> Just a friendly reminder) Rebased and ready to be merged — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#34714 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALpCsPjBEtgUFnTVUO3nqRJvQBjrbO0gks5vMz6hgaJpZM4ZUgja> .

-- — name_en: “Yuzuru Nakamura” name_ja: "中村 譲” mail: "shnsprk@gmail.com"

[kaspth]

Hey-oh!! I thought there was something I needed to look into with this, which is why I kept procrastinating, but nope, it's all good! 😄❤️