sr_mini VS good_job

I recently created a very small single file Rails app to help you learn about (and tinker with) StimulusReflex and CableReady. You can literally be up and running in a matter of seconds. https://github.com/hopsoft/sr_mini

Every author of the free software obviously has rights to full control of the scope of their project.

That being said, I regret that we have switched from good_job (https://github.com/bensheldon/good_job). The thing is - Basecamp is a MySQL shop and their policy is not to accept RDMS engine specific queries. You can see in their issues in Github that they try to stick "universal" SQL and are personally mostly concerned how it performs in MySQL(https://github.com/rails/solid_queue/issues/567#issuecomment... , https://github.com/rails/solid_queue/issues/508#issuecomment...). They also still have no support for batch jobs:

Advisory locks aren’t all sunshine and rainbows. They can only be unlocked by the Postgres connection that acquired the lock. That means you need to track the connection, typically by dedicating a connection to the job that needs locking.

Here’s a good issue describing the tradeoffs between a lock table and advisory locks.

https://github.com/bensheldon/good_job/discussions/831

Good Job does the same for Rails

https://github.com/bensheldon/good_job

I wish I got told "good job" 👍 every single day. Rather than telling you what a good job you did, GoodJob provides a multithreaded, Postgres-based, Active Job backend for Ruby on Rails. This newest version resolves deferred database schema changes, and removes deprecated behaviour. It's been two years since the last major version update, and there are over 100 patch releases from 88 contributors including new batches, bulk enqueuing, labelled jobs, job throttling, dark mode for the web dashboard, and tonnes more. Read about them all in the GoodJob Discussion post.

The background processing gem we'll use in the expense tracker app is GoodJob, but you're free to use whatever suits you.

This is the most direct competitor of good_job in my opinion.

Once we are done with default gems, should we look into something we usually use? That's jwt because we need session tokens for our API. Next comes our one and only sidekiq. For a long period of time it was the best in town solution for background jobs. Now we could also consider solid_queue or good_job. In development and testing groups we need rspec-rails, factory_bot_rails and ffaker. Dealing with money? Start doing it properly from the beginning! Do not forget to install money-rails. Once everything is added to the Gemfile do not forget to trigger bundle install.

In the world of Ruby, GoodJob [0] has been doing a _good job_ so far.

[0] - https://github.com/bensheldon/good_job

For Rails apps, you can do this using the ActiveJob interface via

https://github.com/bensheldon/good_job

Had it in production for about a quarter and it’s worked well.