Thanks for the video. Can you do a comparison of Hangfire, Coravel and Quartz, please?

Quartz is extremely reliable and works very well. Hangfire is a very heavy dependency, I'd only adopt it if I really needed it.

The title of the video sounds like a clickbait. I think you need a comparison video why is it better than other similar libraries, e.g. Quartz, Coravel, FluentScheduler.

@ThugLifeModafocah

17 күн бұрын

Agree.

@LuisAlonzoRivero

17 күн бұрын

Quartz FTW!

@DanBottiglieri

17 күн бұрын

I love Nick and pretty much watch all his videos but bless him, he does love the clickbait titles and images.

@Daniel15au

17 күн бұрын

For a small site where you don't need fancy features, Coravel is the easiest one to use by far. I love it.

@sabientje65

17 күн бұрын

Nick almost always uses clickbait titles. Often has the opposite effect on me making me not watch his videos lmao.

Hangfire is solid but you should try Quartz. Over time I have replaced hangfire with Quartz in most of my projects. I find the extensibility and performance better

@danilonotsys

18 күн бұрын

Perfect comment. Even to do a simple benchmark Hangfire can be a pain due to its heavy static based usage. But after looking into the source code and managing to find its proper instance structures to benchmark I have found that Quartz performs much better. Hangfire also seems to have some kind of internal process that runs from time to time that causes some hanging and delays the scheduled tasks by some seconds (up to 20s)

@adedoyinphilip8647

18 күн бұрын

Hang fire doesn't do well in a containerized environment. The workers stops working at some point and that affects recurring tasks. quartz is better especially in containerized environment.

@da3dsoul

17 күн бұрын

Quartz is in the middle of a rewrite for nosql and other improvements, though, so support is currently slow or lacking

@amrswalha

17 күн бұрын

Totally agree, Hangfire almost the same no updates or major enhancements for many years. Quartz does the job and more.

@tyomidi

17 күн бұрын

Also agree, I would never recommend Hangfire over Quartz unless a commercial support contract was mandatory.

Perfect timing on this video! I am just starting to build an application that needs to execute tasks on a background service, with a follow-up n hours later AND have scheduled jobs. Hangfire looks to do all of that and includes a nice dashboard to boot. I will also look at some of the other libraries mentioned in the comments--Quartz, Coravel, FluentScheduler. Very excited I won't need to build from scratch :D

Wow! Awesome library! I will definitely be checking it out. Thank you Nick!

Thank you Nick for listening to us and making valuable videos again ❤

Please make a video to show all possible things we can do with Hangfire. I love your content so much.

It'll be nice to have a deep dive into hangfire

Could you make a comparison to Quartz. We are using Quartz but had some problems of scheduled Jobs that were never executed (due to a Bug I then fixed in v3.4). In addition we needed to extend a bunch of extra stuff. So, would be nice to know if there is another scheduling framework which is worth it switching.

Have used Quartz, HF and Coravel and for me personally, choosing one over another depends on the environment and app requirements.

Big fan of hangifre, I use it heavily at work and would love to see a deeper dive into how you use it!

Used hangfire in production for 4 years now, never had any issues and a great builtin dashboard

Thank you a lot, you are not going to believe the timing of this video is inch-perfect.

Another solution to consider is employing an external job scheduler that triggers tasks via API, effectively decoupling processes in an elegant manner.

We also use this a lot in our projects. With some nice extension packages you can have progress bars in the dashboard wich is cool. The dashboard itself is useful, but if you have a lot of jobs that get triggered very often it can become cumbersome to find an invokation of certain job types. Some sort of filter on date or job would be nice.

@PaulPendor

7 күн бұрын

Hi there. Apologies if you already know this, but thought I would offer a suggestion. You can give your jobs a Display Name and incorporate instance arguments into the name. The display name is then displayed as the job name in the dashboard. This doesn't solve the problem of being able to search for a specific job, but you could for example set your paging to 50 or 100 per page, and then use the in browser search. Your code might look something like this: public class MyJobClass { [DisplayName("Job for customer {3} with argument {0} and number {1}")] public async Task MyJobMethod(string argument1, int argument2, string customerName) { .... // Your method code } } This can be helpful for tracking down specific instances of regularly run jobs.

I have used hangfire I generally like it. Dashboard is good but not properly documented how to secure it. Having multiple servers is a good benefit to scale. dashboard security and scale with multiple servers are the next video post ideas from me. Perhaps it's good to mention about async await problem of it too

@Daniel15au

17 күн бұрын

To secure it, you need to pass an authorization filter in the options for UseHangfireDashboard.

@spacemanjack777

15 күн бұрын

Curious, what's the async/await problem?

We've got a private/custom implementation for recurring and on demand tasks actually. Likely because we've had this need for many, many years now. But having a fully custom thing does have it's own advantages (and some disadvantages too of course, mostly in cost to build + maintain it). However, that's mostly legacy at this point though, since most projects these days are cloud first and as such Azure's replaced all of that. Basically, Azure Functions are generally the first stop for whatever needs to happen. Easy enough to get those scheduled if need be.

Seems very cool, I would love to see an advance use cases video!

An in-depth video on Hangfire would be awesome!

Really interesting, I'd love to see more in-depth preview, especially since I've been looking at Microsoft's Durable Functions, but also been wanting to move away from requiring MSSQL (esp since they don't support an ARM64 Docker container atm).

Hangfire is amazing. And their dashboard too. The worst part of the engine, that their client API is still synchronous meanwhile the most of storages they use have asynchronous API. Anyway, it works fine executing asynchronous methods enqueued.

Interesting content. Thanks! I still prefer message based scheduling, like Azure service bus or even rabbit mq, no pooling necessary.

Surely Nick you have played around with the scheduling options that you can build in .Net Core? What are the drawbacks that make you prefer Hangfire?

Hi Nick, quick question. If you want to schedule jobs but also queue tasks. Would you recommend using this solely. Or would you only use this for scheduling and then something like Mass Transit for queuing?

I think a video about scaling out would be cool. So many asp core api's are setup using scaleout in some way or another. So how do i make sure a job is only executed once across the instances of my api. Can i have another aspcore api be the worker and others be "enquers". Stuff like that. Looking forward to more of your videos !

My company has built in-house a background worker ui. It shows what background tasks are running, and how many instances of each per host, and we can scale up/down per host through the dashboard if needed It would be cool if we could move it to something off the shelf. I'd love a deeper dive if something like this is possible.

Hi Nick. Please make more videos about Hangfire

While I love Hangfire and we also used it in various production environments, my by far biggest problem is that under the hood everything is static. While the surface looks nicely integrated into the .net service architecture, it actually really isn't. This makes it absolutely impossible to write reproducable integration tests because there is no way to reset the state of the objects.

@Kirides

17 күн бұрын

i agree, while i understand that hangfire is from a time looong before ServiceCollection or other "modern" patterns (like a non-static builder pattern) i really wish that hangfire upgrades to a non-static builder. I really see no reason not to. If i want a static IJobScheduler, let me do that, but don't force it on me (have everything available static even if i don't want).

@nilphilus

14 күн бұрын

I do personally created some 'system tests' which is pretty much reproducable. (except the part when it is affected by other service - but you might prepare similar thing with more static data). However initial phase of it is to drop and recreate database and start from 'blank environment' -> next step is to create a HangfireServer which is assigned to 'test customer' (each server which we have is responsible of different customers with different databases) - after that I've created a 'WaitForJob' method which works on while loop searching for not finished (failed) jobs and let rest of the process to continue when it is '0'. but indeed - there is a lot of static and is like part of documentantion also in places when you have other options. Dashboard however is a bit annoying, becouse if I want to cover new 'customer database' it have to be re-released becouse route have to be registred

Would very much like more info on this! Looks really nice, especially since it's not a windows service!

Hello everybody I'm Nick

@jacobmars1902

18 күн бұрын

no, i am

@margosdesarian

18 күн бұрын

@@jacobmars1902 No, IM Nick, and so's my wife

@griffonethousand

18 күн бұрын

I’m Nick and so is my wife!

@BetrayedEnemy

18 күн бұрын

It says in your Username you are Philip tho

@philipmrch8326

18 күн бұрын

@@BetrayedEnemy I'm Nick

Yes i do use hangfire in production, its reliable but need some validation and etc if job run long time it can be run again even if the job still run

@nickchapsas

18 күн бұрын

Yes, you need to make sure that your job processing is deterministic

@AndersReinhardtHansen

18 күн бұрын

Buy the full version, this can guarantee that jobs do not run more than once even across different deployments

@Kingside88

18 күн бұрын

Unfortunately my post was deleted. So can use it this way: private readonly ReaderWriterLockSlim locker = new(); public void MyReccuringTask() { try { locker.EnterWriteLock(); // Do your stuff } finally { locker.ExitWriteLock(); } }

@emllik2155

17 күн бұрын

Have you tried increasing invisibility timeout/sliding invis timeout? It's 30 min by default iirc so any job that takes longer than that will start over

Best video thanks!

It's the first time I'm hearing of Insomnia. Is this what you prefer using over Postman or is there certain features Insomnia has over Postman that makes it better?

@karpovv_boris

15 күн бұрын

It’s matter of taste in general or what’s in use in company you working at. In fact it’s all json files and ui - forms and buttons, cli or your preferred prog language script.

@RaMz00z

11 күн бұрын

Insomnia is way better at saving params and collections in a Git friendly form (although not perfect), making usable for sharing across the team. And I think it even has a free feature for sharing, but not sure on that one.

can you make it cluster aware using the settings ? if yes dose it take a strategy like round robin ... etc ?

Yes we want more Hagfire!

I am using it for years and it's very very reliable

Nik finally switched to a new JetBrains IDE design

How do you prevent the IIS hosted app from going into idle? How do you authenticate the dashboard using Azure AD?

Please make that video! Very interesting stuff.

I’d use Quartz instead, at least for simple scheduled jobs that does not need any admin gui.

What do you mean "trust"? These are open source, you can look at the code. That being said if you want how everything works you should be using timers (and eventually roll your own scheduling system).

HF just works and fairly simple and easy to setup

How about securing dashboard (exposing it only to authenticated users) and splitting it from the project to a different domain?

Hello, I can't find the monthly subscription on the website, I think I have seen it at some point. I don't know if it's a bug on the website or it's just something I imagined. It would be great to have her back. Greetings!

@nickchapsas

18 күн бұрын

There is no monthly subscription and there won't be until at least mid to late 2025

@mr.nobody4494

17 күн бұрын

@@nickchapsas sad

This is very cool, but I can't really think of many use cases for this. What are people using it for?

I also liked Coravel

Is it next possible ? - have web API with Hangfire as described in the video but only for job registrations - have a separate service (several may be) on different host\hosts connected to the same Hangfire database but actually processed registered by API jobs.

@spacemanjack777

15 күн бұрын

Yes. Hangfire separates the client (job scheduling) from the server(s) (job processing). They don't have to run on the same host. Common approach is to deploy a Windows Service as a server instance. You can have multiple servers that are processing the jobs. They just need access to the Hangfire data storage. And for each server you can specify if it should only process jobs from specific queues (default is to process from all queues).

I use Hangfire, but sometimes it happens my job is run twice (I have 3 replicas in k8s). Maybe its because I'm using redis with two replicas as job storage?

I didn’t find it super reliable, maybe it was the version I was on but things like attributes for controlling concurrency and retries just wouldn’t behave. I got on better with queues and serverless functions myself, which ended up being cheaper than hangfire as well as you don’t need the always on compute sat there polling and costing money.

@RaMz00z

11 күн бұрын

Concurrencies and retries are not Hangfire's responsibility but your code's. It is not meant for executing complex code. Call a webApi if you need to do that.

@mip83

11 күн бұрын

@@RaMz00zWhy does it have concurrency and retry attributes then?

One thing that wasn't clear in the video, when the scheduled job runs, is that code executing on the hang fire server, or is it doing a call back into the dispatching service and running the code in the service? If it's calling back into the service for execution, how does that work? When you have multi nodes of your service, does it always call back to the exact instance of your service that dispatched the job? Could that end up hotspotting execution? Thanks!

@JasonSobell

17 күн бұрын

It's running in the server instance. Everything needed to run the command has to have been serialised, and if you are running a custom class you need to make sure that DLL is present and registered on each destination server. Job dispatching is done from outside of the service, so there is no 'call back' occurring. In theory you could insert a record straight into the database from a command prompt, and one of your Hangfire server instances would see it, consume it, run it, then save the result in the job result. Remember that this is not some form of RPC, it is a scheduler, so as far as client apps are concerned it's fire and forget. You have API calls to request the status of jobs by your own criteria, so you might add a GUID to your job data, then poll Hangfire afterwards and ask it if the job with that GUID passed or failed, but it is a scheduler. I use this for large scale ETL processes and client emailers, with custom jobs. I run thousands of jobs per day, and send out hundreds emails, each being its own job. I can check the failed jobs list in the Dashboard for problems, and rerun them manually. It is an extremely powerful system, and the Dashboard makes it more acceptable to clients than Quartz.

@RaMz00z

11 күн бұрын

As said, it''s run on the server. If you need scalability (and don't want to send a bunch of dlls to another server after each build...), use a webApi endpoint on your main application. It may be slower, but you never will need to touch your Hangfire server. Or messaging. Messaging works too.

@JasonSobell

11 күн бұрын

@@RaMz00z I'm not sure what you're suggesting here. Creating a webAPI prevents scalability, as it's a single endpoint. Whatever you do for scaling you will have to distribute custom DLLs (unless it's a simple enough function to serialise as in Nick's example which is simply auto-self-deployment). This is not a disadvantage or negative, it's just a necessity when you have custom code. You could deploy your solution to an image then run it scalable on Azure or AWS, as Hangfire will simply add them as new servers available to process tasks, but the whole point of a scalable service is that it can run on separate resources to allow parallelism. Funneling it back into a webAPI seems to defeat the purpose of a scalable solution.

I need a scheduling library that uses "circuit breaker - retry policy" pattern. Not on job level, bu across jobs. What I mean by that is the ability to group jobs by some sort of typing. Firt and foremost when they fail - how they fail. Let's assume I have many instances of the same job with different parameters, but relying on the same third party service. Or different jobs using that same service. And let's suppose that service is unavailable for some period. I need a mechanism that can put on hold all subsequent job instances relying on that service if N consequent attemtps to use it fail (spread in the job queue), and have some retry policy, that can even put them fully suspended after M failed retry sessions, but with the ability to switch "manually" that circuit breaker back on. I am aware of both Hangfire and Quartz, bud haven't used them yet. Is any of these or any other similar tool providing something like this?

@RaMz00z

11 күн бұрын

That's not the job of *any* external library, that's the job of your application code Polly is a nice library to do that

After working a lot with Hangfire i kind of have to disagree on it beeing the scheduler you should use. Yes its a solid solution but for staging with a single db and multiple devs its at least for me a bit frustrating whereas coravel shines with its simplisity. Dont get me wrong i do thing i didnt dig enough to get it working as i want it too but mostly you dont want to dig that deep

Been using this for years.

I made my own scheduler with only five scripts. A tiny library that can run every and execute any action that you throw in there, using cron expressions .You have also full control of the action because it returns a unique Id every time you schedule a task so you can cancel it at any point by api call.

@RaMz00z

11 күн бұрын

Hangfire sends an ID that you can cancel as well.

how about compiring hangfire to Coravel ??

Why would I use this instead of windows task scheduler

What if the prod user is iis don't have permission of create table?

Hopefully integration with Aspire will become available soon.

Hangfire still executing everything (jobs, interacting with the storage) synchronously which is a big bummer. Everything will be a blocking call under the hood.

Hangfire looks good, but personally I prefer Quartz 😅

Since dotnet core, when hosted inside IIS, Hangfire goes down when app/api goes idle. Hence scheduled jobs are not executed on time. None of the solution worked for me ever and I moved to dotnet background workers (WS). Did anyone else faced similar issue, or was it only me doing something silly?

Hangfire causes some high cpu usage on my dedicated server sometimes

I don’t get the point of hard coding of adding jobs in the code, does the dashboard allow me to add jobs dynamically?

@RaMz00z

11 күн бұрын

Not to my knoledge no, it isn't the usage intended. Hangfire uses code static anylisis to serialize the code needed to be executed. How would you do that in a web form ?

isn't serverless already replaced it?

Once my database reached its storage quota causing website downtime.. Hangfire did not delete its jobs

@RaMz00z

11 күн бұрын

Doesn't do any deleting by default, but there's a param for that

Why just do not use a message broker with default dotnet background worker (hosted service)?

@RaMz00z

11 күн бұрын

Cannot do scheluding, i.e. executing code in the future or every monday at 6

I had to dump hangfire for quartz net because hangfire retry policyfor schedule jobs doesn't work as expected, and it does not allow me to run jobs in parallel.

@spacemanjack777

15 күн бұрын

Care to elaborate? I though parallel jobs with Hangfire were kinda the thing it was supposed to do (other than scheduling) based on the worker count? Maybe I have misunderstood something.

I have been using HangFire for a while but I don't like that I need to have the connection to the data storage every place I use the scheduler, there is not a concept of HangFire Server and HangFire client libraries.

@RaMz00z

11 күн бұрын

You can use the SideCar pattern for that. Basically you have one specific service that has those infos, and you call that service when needed. By means of webApi or messaging.

@MrIsrael3000

11 күн бұрын

yeah, this makes sense in certain scenarios, however I pretended to use Hangfire as a separated pod or as a separated service, to manage scheduled services across organization, maybe is not intended for this scenario.

How much are they paying you

Hangfire is great to do background job but the dashboard becomes really slow after some time because of past data.

@RaMz00z

11 күн бұрын

You can setup a cleaning policy on the server (I'm pretty sure). Or just clean the database yourself.

@hafizabdullah7488

9 күн бұрын

@@RaMz00z yes, that is one of the way but it does not help for case like you want to process thousands of data on a day and you just want to monitor of what went well and what went wrong. You open the dashboard and it feels really slow.

Neat Ad

Does HangFire support Timezone scheduling yet?

@emllik2155

17 күн бұрын

Yup, TimeZoneInfo is an optional parameter when scheduling recurring jobs

How do you debug it? The usual way?

@spacemanjack777

15 күн бұрын

Yes

Hello Nick I’m everybody

Ciao Vittorio, bene colpani, buon gregario. Per Luis Alberto ripeto quello che dico da vent'anni, non capisco perché aspettare le offerte, Le società serie sono proattive sul mercato perché preferiscono monetizzare il giocatore piuttosto che lasciare che il morbo covi nello spogliatoio fino a corrompere tutto il gruppo come più volte denunciato da Sarri

there is so much ways to create background threads, I would not use this lib at all. Only if I had to

@RaMz00z

11 күн бұрын

It's not intended for background threads but for scheduling. Even tho it can effectively do that as well

What IDE is he using?

@eqwerty610

18 күн бұрын

Rider

@tedchirvasiu

18 күн бұрын

Rider

7:28 What's Insomnia?

@IvanSlater1978

17 күн бұрын

Postman alternative.

Hangfire is terrible. I’ve had cases where I’ve disabled schedules and they still run. The database has a fully qualified namespace to a method that will run and it invokes them when it shouldn’t.

This Hangfire gives me so much headache everyday...

@jeromewilson

18 күн бұрын

What kind of issues have you had?

Hey Nick. Where were you born?) just curious

I would rather see a video that explains how to make your own scheduler. Hangfire is badly implemented, Quartz requires a big chunk of manual labor, and Coravel is behind a paywall. Making your own is very easy anyway.

@AndersReinhardtHansen

18 күн бұрын

Not invented here, why use other people http servers and messaging frameworks, when you can do it yourself.

@fusedqyou

18 күн бұрын

@@AndersReinhardtHansen My point is that you can easily write a scheduler that does the job instead of using a library that either contains a massive amount of overhead or doesn't to the job you expect it to do.

@TuxCommander

18 күн бұрын

Agreed. The only reason I tested Hangfire but was using Quartz in the end, was the convenience of CRON expression. However, even Quartz generated some headaches, which motivates me to make an own scheduler. The mess with timers in .NET and how to pick the right one, was the "hardest" part of it. If you need a scheduler only, build one and sleep well.

@AndersReinhardtHansen

18 күн бұрын

@@fusedqyou yeah and that is my point, you cannot make a better scheduler in the time it takes to setup a hangfire job. There is also the added advantage in the fact that if you have used hangfire before it is even faster yo setup and read the code.

@fusedqyou

18 күн бұрын

@@AndersReinhardtHansen I think this is up for debate. Most people can just write a simple timer to satisfy their needs of a scheduler. I didn't spend longer than a day to write a basic scheduler that handles multiple tasks in a specific interval, so if there was an actual tutorial on it then anybody could make one.

This course advertising is so anoying

Problem is, it was developed from Russia. I introduced it with a customer 1 month before the war and I was unable to get the licensed version which I requested, because of company policy. Edit: is is no longer based in Russia

@guy-heylens

18 күн бұрын

Started in Russia, they are now in Estonia. Same with Jetbrains, do you stop using Jetbrains as well?

@xelesarc1680

18 күн бұрын

I thnk hangfire is free are

@AndersReinhardtHansen

18 күн бұрын

@@guy-heylens they moved during the war, jetbrains before. It was not my choice not to use it. The decision was done in the purchase department. And at that time the company was based in Russia, they were writing a blog about moving to Estonia.

@AndersReinhardtHansen

18 күн бұрын

​@@xelesarc1680the basic version yes. I needed the pro version.

@dangg44

18 күн бұрын

What stupid reasons, just because it is "Russian" software. What a pathetic world we lived in? We wouldn't even have to use American software at this point if we were consistent

very buggy lib, this is a promotional video

First comment! Send money. 😂