Hacker News Reader

Comment by chriszhu12 | Hacker News Reader

Another small thing to consider: Adding redis to your stack adds a new failure mode. A service I built a while ago was running on Heroku where Redis add-ons aren't cheap, and our Redis would always running against memory limits, which would cause our entire service to fail.

Meanwhile, 250GB Postgres server has been churning along no problem.

Also, conceptually, architecture where state = DB, and business logic = web server is generally easier to reason about during service migrations and such.

If you don't use ActionCable which I think is the other core feature that relies on Redis, being able to remove it would've saved me a lot of early morning firefighting.

View on HN

This is exactly why I stuck with DelayedJob after all of these years. The community seemed to flock to Resque or Sidekiq, but I always felt my needs were met just fine with Delayed Job. I never was interested in adding more unnecessary complexity to our dev and staging environments for a trade-off I didn't need (there wouldn't be a significant performance increase for my needs).

I've seen this pattern happen with a lot of Ruby projects: there's a popular Gem that people use that grows over time, then someone writes a blog post about why that package isn't suitable for their needs due to a design trade-off (often introducing a new Gem that is advertised as superior to the previous one) and then suddenly the old Gem stagnates, causing the maintainer to lose interest and updates stop pacing Rails versions. Sometimes the old Gem gets deprecated altogether and maintainers stick a big DO NOT USE sign at the top of the github README, all but guaranteeing there is no further community traction or organization for the project.

Meanwhile those of us using the old project chug along with a forked Gem that we cobble a bunch of patches into to meet our needs because there's no longer a centralized place to contribute to anymore. In some ways it's the double-edged sword of OSS. Maintainers aren't obligated to stay as maintainers of course, but it does get frustrating how quickly the community is willing to drop support of things that a lot people are using in production systems.

It definitely makes me reconsider the "don't reinvent the wheel" advice that is so adamantly thought of as a common sense convention in our craft.

That’s exactly why I implemented my own queue system. If it’s something that will only take a few hours to build, and I’ll need to maintain it long term, I’ll always favor rolling it myself.

There are very few “feature gems” that I’ve used in the past 15 years doing Rails development that I’ve been happy I used a year later. Development gems on the other hand like byebug are usually fine.

Maybe repo sponsorships/bounties would help. There could be a basic maintenance bounty that could be chipped into, it could build up over time and then occasionally any of the repo contributors could jump in and tackle a bunch of PRs and issues all at once and pick up the pool of cash.

Yeah I mean if your project doesn’t get huge amount of usage, DJ is fine and quite simple. Unfortunately at any moderate scale or above a RDMS backed jobs table doesn’t cut it

>Unfortunately at any moderate scale

The problem here is the definition of moderate scale and huge amount of usage.

We handle tens of millions of events per year using our primary RDMS as a queue with absolutely no problems at all. The vast majority of projects for most companies aren't going to get bigger than that.

If you have millions of users sending out tens or hundreds of messages per day, sure, that's a huge amount of usage.

That is why sometimes these Gems should be folded into Rails itself, assume it fits the need.

Reply on news.ycombinator.com