lago
lago copied to clipboard
[FEAT]: Ability to replace Sidekiq to Shoryuken Worker
Is your feature request related to a problem? Please describe. Because Sidekiq is a Redis based worker and in AWS environments running a Redis service can be quite expensive I would propose to give ability to choose a different worker in an configurable-Interface-way so the backward compatibility is preserved. This would give possibility to use Shoryuken as a drop in replacement.
Shoryuken uses SQS as a queue which is cheaper/more scalable for larger installations. For local dev/on-prem installations one can use e.g. Elasticmq as a broker (avaiable as both standalone and docker image installation with in-memory/persistent storage)
Hey @maciejstromich,
Thanks for your suggestion.
We will discuss it internally and come back to you soon!
Hey @maciejstromich,
We are following a planned roadmap for the next 6 weeks, but we consider improving this on the tech side afterwards.
Hope this works for you!
Regards
More generally it could be nice to support any ActiveJob adapter.
From what I can see this should be possible with a minimum of changes as the jobs I have looked at only use ActiveJob features and nothing specific to Sidekick, so introducing an ENV var for job backend and then conditionally loading the relevant gems based on the ENV var should work.
We are fond of Que or GoodJob which use Postgres as the backing store, allowing transactional job enqueuing without any extra work.
Agree. Depending where we deploy, we may want to use the native queue infrastructure like Amazon SQS, or Google Cloud Tasks, etc. The same goes for the clock worker, where we would want to use Cloud Scheduler for example. It's great that you already separated that module so we can drop in our own.
Can I ask, is the Redis dependency only used for the message queue, or is it also used as a cache/database?
Logged here: https://getlago.canny.io/feature-requests/p/ability-to-replace-sidekiq-with-shoryuken-worker