Document comparison of GoodJob with other backends

[oyeanuj]

Hi @bensheldon, thanks for open-sourcing this.. this looks great!

Curious if you can share a high-level feature comparison (apart from architectural generational differences), either here or on the README with other queueing libraries like Shoryuken and Sidekiq?

[bensheldon]

@oyeanuj Awesome suggestion 🎉

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

[oyeanuj]

@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!

[hlascelles]

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!

[bensheldon]

@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?

	Multithreaded	Database	Integrity	Latency
GoodJob	✅ Yes	✅ Postgres	✅ Yes	✅ Postgres LISTEN/NOTIFY
Que	✅ Yes	🟨 Postgres, requires structure.sql	✅ Yes	✅ Postgres LISTEN/NOTIFY
Delayed Job	🟥 No	✅ Postgres	✅ Yes	🟨 Polling
Sidekiq	✅ Yes	🟥 Redis	🟥 No	✅ Redis BRPOP
Sidekiq Pro	✅ Yes	🟥 Redis	✅ Yes	✅ Redis BRPOP

[bensheldon]

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".