Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there anything fundamentally preventing a message_bus ActionCable adapter? #163

Open
seanpdoyle opened this issue Aug 4, 2018 · 1 comment

Comments

@seanpdoyle
Copy link

seanpdoyle commented Aug 4, 2018

I want to preface this issue by thanking you for your work on this gem (🎉), and emphasizing that this isn't a feature request.

Are there any fundamental conflicts that would prevent some inter-operability work to be done in support of an ActionCable adapter?

From the front-end side, it looks like an ActionCable.Consumer accepts an arbitrary URL (ws:// or https://).

On the back-end side, there are already several adapters, including adapters using Postgres and Redis.

I've only recently started working with the message_bus gem (so please correct me if I'm wrong), but as I understand it, the ActionCable::SubscriptionAdapter::Base API (i.e. broadcast, subscribe, unsubscribe) seems similar enough to the MessageBus API (i.e. publish, subscribe, unsubscribe) that some glue-code could be written to make the two compatible.

@SamSaffron
Copy link
Member

Are there any fundamental conflicts that would prevent some inter-operability work to be done in support of an ActionCable adapter?

The only fundamental issue I can think about is that message bus is inherently reliable and action cable is best effort.

I am not sure how interoprability really would look, but I guess you could pull something off. The underlying paradigm mismatch though is not easy to solve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants