pongdanaiNil / code-challenge-api

0 stars 0 forks source link

[Question] Why using Sidekiq workers directly instead of ActiveJob? #6

Open olivierobert opened 1 year ago

olivierobert commented 1 year ago

WHen implementing background jobs, the Rails framework provides a built-in solution: ActiveJob. While Sidekiq workers can be used too, I would like to know more about your motivation to use it over ActiveJob.

pongdanaiNil commented 1 year ago

I designed the job service to be separate from the rails application server because, when performing a keyword search with ActiveJob, the rails server must handle both the request and the background process. That is a lot of work for the server and can affect server performance. Separating the worker from the server allows both components to run independently and use system resources more efficiently. The server can focus on handling incoming requests, while the worker can handle background jobs without affecting server performance.

For a standalone job processing tool, Sidekiq is a popular and reliable one. It is also lightweight, so I designed it to use Sidekiq. And in the production environment, separating the worker from the server makes it easier to maintain and update each component independently.

olivierobert commented 1 year ago

Sidekiq can be used via ActiveJob, and a separate process to run Sidekiq jobs can allow the separation from the web server process. So your rationale is not entirely correct 🙈

The question relates more to why using Sidekiq worker over ActiveJob classes. And there are valid reasons to do that, mostly revolving around having access to all Sidekiq options. While ActiveJob supports Sidekiq, it is an abstraction layer that needs to support other background job backends. As a result, ActiveJob API does not expose all of Sidekiq API. You can learn more in this article.

pongdanaiNil commented 1 year ago

Sorry for the delayed response and for misinterpreting your question because of my careless reading.

I never used Sidekiq via ActiveJob before because I understood that would add more complexity and create limitations in the per-job customization. It also affected apps' performance because ActiveJob needed to translate job processing requests into a format that Sidekiq understood.

If my understanding of this matter is incorrect, please kindly inform me. Furthermore, if you have any suggestions, please feel free to share them.

olivierobert commented 1 year ago

Using ActiveJob directly is usually simpler as it comes built into Rails 😅 However, the tradeoff is that ActiveJob provides fewer options than Sidekiq Workers, so it is trading simplicity for fewer options. I am not sure there is a performance trade-off, but there could be one. So for simple use cases, ActiveJob is usually sufficient, but for an application relying a lot on background jobs, it would be worth investing in using Sidekiq Workers directly.