Document comparison of GoodJob with other backends about good_job HOT 5 CLOSED

@hlascelles Thanks for the question. You're right that the overlap of features is very similar. The differentiators for me, that might not matter to you is:

• GoodJob is much simpler than Que and GoodJob solely targets Rails/ActiveJob. I've personally been blocked waiting for Que to be patched when Rails upgrades.
• GoodJob specifically targets schema.rb compatibility. Que requires changing from schema.rb to structure.sql because Que uses database triggers. That means GoodJob is likely slightly less performant than Que, but thats the tradeoff for simplicity/compatibility.

I need to think about how to present these things in the Readme. No matter how I present it, GoodJob's Readme will be biased towards GoodJob. It's also threading a needle because in no way do I want to imply that any other queuing backend is inadequate. They're all great, history has shown that, but each serve different use-cases and needs.

What do you think of this comparison?

from good_job.

@oyeanuj Awesome suggestion 🎉

Could you take 2 min to let me know what non-architectural questions/categories you are curious?

from good_job.

Could you do a section in the README comparing it directly to que?

As I understand it they are both high performance, postgres backed, ruby language async job workers with retries, named queues and the DB ACID guarantees. We've used que for years and it works very well.

It would be great to hear the pros and cons of each!

from good_job.

@bensheldon Sorry that I missed the notification of your instant response!

As someone looking to choose a library for a project, I was mostly looking for feature comparison around retries, wait, error handling, and failing. I'm not sure this is a very satisfying answer, but mostly it boils down to better understanding the tradeoffs of using this vs sidekiq or shoryuken (for eg, implications of using Postgres vs Redis)

Hope that is helpful!

from good_job.

Thanks everyone for the feedback! 🙌 I've updated the readme to include the table. It's behind a <feature> expander because I wanted it near the top but also didn't want it to overwhelm and distract from "getting started".

from good_job.