Document Rules on how to write a Sidekiq Job

[jmarsh24]

a few ideas

• always set explicit retry settings
• always set a priority
• figure out which queues we need and what their priorities are
• create mixins for unique jobs (e.g. availability update) and rate-limited jobs (e.g. jobs calling external apis)

[jmarsh24]

https://github.com/toptal/active-job-style-guide

I found this article which seems pretty in-depth on how to use active_job.

@nerdgeschoss/nerdgeschoss maybe we can all read through this and voice our opinions on what we think should be highlights and also rules that we follow on our internal projects?

[Adeynack]

• always set explicit retry settings

That was required by @JensRavens on a meeting some weeks ago. This goes in 👍🏼

• always set a priority
• figure out which queues we need and what their priorities are

This is more like always set an explicit queue, which will determine its priority.

• create mixins for unique jobs (e.g. availability update) and rate-limited jobs (e.g. jobs calling external apis)

Rate limiting raisable errors should exist in the class where the API is being called. The job can however then set specific retry strategies based on specific errors being raised. See discart_on and retry_on). We have to see how well those work with Sidekiq, since they are ActiveJob concepts. There are however ways of also doing this directly with Sidekiq.