How to share a worker between two different applications on a hero?

Question

I have two separate applications running on heroku and pointing to the same database, first responsible for the user interface , and the second for the admin interface , I use sidekiq with redis to handle background jobs, I added one working one, and I can share "redis-server" by setting an environment variable pointing to the same Redis that provides Addon. Now I want to share with the employee, because adding an additional worker will cost twice.

Please suggest whether this is possible or not?

Answer 1

If both applications use the same Redis URL and the same namespace, you can deploy the same worker with the same Redis configuration and they will be shared by both.

Please note that your Sidekiq process will download one application or another. The code for your Workers should be in this app. Another application will not be able to reference the code, but may click on tasks using:

 Sidekiq::Client.push('class' => 'SomeWorker', 'args' => [1,2,3]) 

Note that the “class” is a string, so SomeWorker may be defined in another application.

Answer 2

How to use 3 different heroku apps?

• User Interface Application (ui repository)
  • web: bundle exec rails server
• Admin Interface Application (Admin Repository)
  • web: bundle exec rails server
• Work (administrative repository)
  • worker: bundle exec sidekiq ( documentation )

Even if 2 and 3 use the same code base, you can have 2 different heroku applications. One that starts the administrator, one that actually starts sidekiq. Does this help solve your problem?

Answer 3

Mike's answer is still a safe bet, although you must include all the relevant sidekiq parameters that you entered into the queue, this class is a little important.

Here is a blog post that goes in more detail and offers a second approach:

http://coderascal.com/ruby/using-sidekiq-across-different-applications/

Basically, the alternative is to have a proxy class in the queue application that controls the sidekiq behavior (queue, retries, etc.). Then in the receive / de-queue application there will be a corresponding class name.

The blog author overrides some of the standard Sidekiq logic to redirect from the proxy class to the non-proxy class on the receiving side. Overriding the behavior of gems is a bit risky, and it provides additional class assignment agreement. But you can leave without doing this part.