Are there plans to support Action Cable with Solid Queue?

[seanpdoyle-intercom]

Solid Queue's internal queueing mechanism makes it a good fit for Active Job, and can serve as a replacement for Redis-backed job queues.

Are there also plans to support Action Cable as an Adapter?

Postgres already serves as a relational database-backed Cable Adapter (through the
ActionCable::SubscriptionAdapter::Postgres class) as an alternative to Redis. Since Solid Queue aims to bring Postgres-like queue mechanisms to other SQL databases like sqlite and mysql, Action Cable could stand to benefit from that work.

What would it take to re-purpose what's already built to serve both Active Job and Action Cable?

[rosa]

Ohhh, good question! That's not currently in my plans because the Action Cable adapter relies on very specific PostgreSQL's features, namely LISTEN / NOTIFY. I'm not sure Solid Queue tries to bring Postgres-like queue mechanism to MySQL, but rather, it tries to implement queue mechanisms using what MySQL already has 🤔 That is, instead of relying on Postgres's queue-like features, it ignores these and relies on other common features (and plain, boring indexes to optimise certain queries) to serve as an Active Job backend. Did I understand your question correctly?

[seanpdoyle-intercom]

Did I understand your question correctly?

I think so, yes.

I'm not sure Solid Queue tries to bring Postgres-like queue mechanism to MySQL, but rather, it tries to implement queue mechanisms using what MySQL already has

My assumption was off base, so thank you for helping to clarify my understanding of those underlying mechanisms. I'd understood Solid Queue to draw inspiration from good_job. The good_job README explicitly mentions:

Backed by Postgres. Relies upon Postgres integrity, session-level Advisory Locks to provide run-once safety and stay within the limits of schema.rb, and LISTEN/NOTIFY to reduce queuing latency.

I'd misunderstood Solid Queue's positioning, and made the mental leap that since Good Job relied on LISTEN, NOTIFY, and UNLISTEN to function, then Solid Queue must be re-implementing those features in a SQL-agnostic way.

If that isn't the case, I wonder what it'd take to provide an out-of-the-box SQL adapter for Action Cable. With Solid Cache serving as an SQL cache store and Solid Queue serving as an SQL job queue, Action Cable is the last remaining built-in framework that pulls in a Redis dependency for production-like environments.

[vishnu-m]

@seanpdoyle-intercom Related thread - rails/rails#50480

[npezza93]

@seanpdoyle-intercom fwiw I made https://github.com/npezza93/solid_cable which adds an action cable adapter for mysql and sqlite.