For the second edition of The Rails and Hotwire Codex, I'm torn between switching to SolidCable, or sticking with the Redis adapter 🤔. I'm sticking with Postgres as the DB, and switching jobs from Sidekiq to SolidQueue, meaning Redis is needed for only ActionCable and Kredis. Any suggestions?? - ThreadSky

ayushn21.bsky.social • 42 days ago

For the second edition of The Rails and Hotwire Codex, I'm torn between switching to SolidCable, or sticking with the Redis adapter 🤔.

I'm sticking with Postgres as the DB, and switching jobs from Sidekiq to SolidQueue, meaning Redis is needed for only ActionCable and Kredis.

Any suggestions??

Comments

ayushn21.bsky.social•42 days ago

Some additional context: I'd like the book to teach the skills needed to work on the vast majority of Rails apps, which is why I'm sticking with Postgres instead of switching to SQLite.

In 2025, I'd imagine Redis is still part of most Rails stacks as the Solid trifecta is still very new.

ayushn21.bsky.social•42 days ago

But, the first edition will always be available for anyone interested in Sidekiq/Redis ... Hence my conundrum, can I drop that stuff in the second edition? 🤔

adrianvalenz.bsky.social•42 days ago

Why not emphasize solid queue in the new edition and do a mini book expanding on sidekiq/redis?

ayushn21.bsky.social•42 days ago

Hmmm, yeah could do something like that. Probably better to tell the reader to refer to the first edition for that stuff instead of maintaining another mini book.

Anyone who buys the second edition will also get access to the first edition.

mediafinger.com•42 days ago

I don't know how different Postgres and SQLite behave with SolidCable, but imo you should switch away from Redis to the solid stack for the new edition. That's how new apps will be created and probably existing apps will be refactored to.

kevenages.duhado.com•42 days ago

We've traditionally used RabbitMQ for pub/sub and will be rewriting to use SolidCable/SolidQueue in the future to simplify infrastructure management (byebye erlang). Around rails 6, we debated moving to another backend, but these changes have us excited about rails again 🙌

ayushn21.bsky.social•42 days ago

Nice, thanks for the insight :). Are you planning to back SolidCable/SolidQueue with Postgres, MySQL, or SQLite?

kevenages.duhado.com•42 days ago

We'd LOVE to back it with SQLite, but we feel so bound to Postres at this point. We're just going to stick with that. We're a very small team, so I don't want to bite off more than we can chew, all at once.

ayushn21.bsky.social•42 days ago

Fair enough, thanks!

mediafinger.com•42 days ago

RabbitMQ for pub/sub sounds like a much better solution to me than a background jobs worker. I would stick to it.

kevenages.duhado.com•42 days ago

It is, especially if you use it to its full potential. But as time has gone on, many features we did use, like websockets, we have other/better options that aren't backend reliant. We also fall behind on infrastructure maintainence constantly, and we're often uncomfortable in that risk

ayushn21.bsky.social•42 days ago

Thanks Andreas. That's what I'm leaning towards too. I'm not sure existing apps will be refactored to this approach though ... Sidekiq/Redis still offers performance benefits which might be necessary in some use cases, but yeah the Solid stack is ideal most of the time.

Comments

Posting Rules

Reply