Migrate to Sidekiq

[artur-intech]

• Check if it supports keyword arguments in jobs
• Use Rails adapter (ActiveJob)

que gem's drawbacks:

• SQL (with table name) is hardcoded (https://github.com/chanks/que/blob/master/lib/que/sql.rb)
• Active Job is not supported (Document ActiveJob compatibility/configuration que-rb/que#127)
• Lack of documentation

[teadur]

@artur-beljajev the first drawback link is broken.
It seems 1.0.0b does support activejob

To we have any other drawbacks ?

[artur-intech]

sidekiq is the de facto standard. It is more sophisticated. It uses nosql to manage jobs, which is more efficient. It's really well supported. que has 386k downloads, whereas sidekiq has 22M. It is therefore easier to support it.

[artur-intech]

@vohmar We could start migration step by step

[maciej-szlosarczyk]

Migrating to sidekiq introduces redis server which needs is an architecture component that needs to be monitored, managed and updated. This is not really a decision we can make without considering the ops part of it.

[maciej-szlosarczyk]

We might be better off with moving to delayed_job instead, which supports postgres as the queue backend.

https://github.com/collectiveidea/delayed_job

[artur-intech]

https://github.com/collectiveidea/delayed_job/blob/master/CHANGELOG.md seems kinda abondoned as well. sidekiq is considered de facto standard these days.

[maciej-szlosarczyk]

I'd say that strong second in popularity and 11 milion downloads is a good bet if maintaining Postgres as backend is one of our goals. At this point I have no reason to assume that it is not.

[teadur]

As of sidekiq would introduce new dependencies to application stack, i would vote for delayed_job.

[artur-intech]

Decided to move to delayed_job.

Closed in favor of #1234.