Hangfire VS Resque

Hangfire (https://hangfire.io) includes default exception handling and is very extensible, I think it's a good mid-level choice and a good alternative to other queue mechanism, if you can't afford to host a separated queue service or can't manage a separated service; also scales pretty well (you can have multiple servers handling the same background job queue, or different queues). It runs on Sql Server and MySql... Source: almost 2 years ago

I used to just use hangfire.io in .net and worked wonderfully for any long running tasks or schedules. Had a great queuing system, UI to know if they failed , etc. That's how I'd send emails, pdf's, and other things along that nature. Then if it were more just a db related operation, just setup a schedule in mssql job service. Source: almost 2 years ago

You can use hangfire for cronjob, to run at a time in future, you can use Hangfire.Schedule(jobid, datetime). Source: almost 2 years ago

So another option is to use something like https://hangfire.io to pull the jobs and process them? Source: about 2 years ago

I've got a fairly large process I need to handle in background on my .net core web app so I've exported it to a background task using Hangfire. Source: over 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 / almost 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