Dramatiq VS Resque

Using something like Dramatiq [1] with Redis, writing a background job takes minutes, and can be deployed alongside an existing Python web app. There are probably JS equivalents. I think Inngest could be a useful service, but the comparison felt off for me - it made me feel like this wasn't solving a real problem. [1] https://dramatiq.io/. - Source: Hacker News / 10 months ago

Hello everyone. We want to present you Taskiq: our new project that allows sending tasks using distributed queues. Conceptually it's similar to Celery or Dramatiq but with full asyncio and type hints support. Taskiq can send and execute async functions and has many integrations with different queue implementations. Source: about 1 year ago

I spent 3 years building a high scale crawler on top of Celery. I can't recommend it. We found many bugs in the more advanced features of Celery (like Canvas) we also ran into some really weird issues like tasks getting duplicated for no reason [1]. The most concerning problem is that the project was abandoned. The original creator is not working on it anymore and all issues that we raised were ignored. We had to... - Source: Hacker News / over 1 year ago

I have been using dramatiq lately (celery alternative) and so far I'm happy with it. Source: almost 2 years ago

If your tasks are idempotent, Dramatiq if intended for your case. https://dramatiq.io/. - Source: Hacker News / almost 2 years ago

You can use a background job queue like Resque to scrape and process data in the background, and a scheduler like resque-scheduler to schedule jobs to run your scraper periodically. Source: almost 2 years ago

So how do we trigger such a long-running process from a Rails request? The first option that comes to mind is a background job run by some of the queuing back-ends such as Sidekiq, Resque or DelayedJob, possibly governed by ActiveJob. While this would surely work, the problem with all these solutions is that they usually have a limited number of workers available on the server and we didn’t want to potentially... - Source: dev.to / about 2 years ago

Background jobs are another limitation. Since only the Aha! Web service runs in a dynamic staging, the host environment's workers would process any Resque jobs that were sent to the shared Redis instance. If your branch hadn't updated any background-able methods, this would be no big deal. But if you were hoping to test changes to these methods, you would be out of luck. - Source: dev.to / about 2 years ago

The Schedules worker corresponds to the appwrite-schedule service in the docker-compose file. The Schedules worker uses a Resque Scheduler under the hood and handles the scheduling of CRON jobs across Appwrite. This includes CRON jobs from the Tasks API, Webhooks API, and the functions API. - Source: dev.to / about 3 years ago

There are a few of popular systems. A few need a database, such as Delayed::Job, while others prefer Redis, such as Resque and Sidekiq. - Source: dev.to / about 3 years ago