Sidekiq Rails 4.2 Use Active Job or Worker? What's the difference

Question

This is my first processing jobs asynchronously I am implementing Sidekiq for background processing in my app. I will use it for reminder emails and in-app notifications. I am

Answer 1

Rails 4.2 added ActiveJob to unify the jobs API but to run it asynchronously you need a background handler, this is where the sidekiq comes from.

Sidekiq already has its worker class but it also implemented the new active job class, so it can work either way.

However, the good thing about active job is that you can change the background handler without the need to change your code, provided they both support the features you want (eg: handling jobs at a certain time; having multiple priority queues).

There's a rails api guide here that contains a good comparison for handlers that support active job, including each handler's supported features. Here's the comparison table if you're too lazy to check the link:

|                   | Async | Queues | Delayed   | Priorities | Timeout | Retries |
|-------------------|-------|--------|-----------|------------|---------|---------|
| Backburner        | Yes   | Yes    | Yes       | Yes        | Job     | Global  |
| Delayed Job       | Yes   | Yes    | Yes       | Job        | Global  | Global  |
| Qu                | Yes   | Yes    | No        | No         | No      | Global  |
| Que               | Yes   | Yes    | Yes       | Job        | No      | Job     |
| queue_classic     | Yes   | Yes    | No*       | No         | No      | No      |
| Resque            | Yes   | Yes    | Yes (Gem) | Queue      | Global  | Yes     |
| Sidekiq           | Yes   | Yes    | Yes       | Queue      | No      | Job     |
| Sneakers          | Yes   | Yes    | No        | Queue      | Queue   | No      |
| Sucker Punch      | Yes   | Yes    | No        | No         | No      | No      |
| Active Job Inline | No    | Yes    | N/A       | N/A        | N/A     | N/A     |
| Active Job        | Yes   | Yes    | Yes       | No         | No      | No      |

Answer 2

I would recommend sticking with native sidekiq for more features. I also ran into some weird serialization issues with ActiveJob once in a while. ActiveJob, while pursuing a noble goal of enforcing unified API, limits many implementations precisely for this reason and offers a little benefit for now IMO. Personally, I'm more than eager to pay the possible price of rewriting the code some time in a future(which may never happen, you don't swap critical parts of your application just for fun - like activerecord vs mongodb) if I decide to swap implementation for richer feature-set.

Answer 3

According to the documentation, there may be performance advantage to using Sidekiq::Worker over ActiveJob.

https://github.com/mperham/sidekiq/wiki/Active-Job#performance

Answer 4

Short answer is they are the same thing. ActiveJob calls it a Job whereas Sidekiq calls it a Worker. I've decided to keep the terminology different so that people can distinguish the two.

You can use either one. Note that ActiveJob does not provide access to the full set of Sidekiq options so if you want to customize options for your job you might need to make it a Worker.