Difference between HangFire and NServiceBus about hangfire HOT 2 CLOSED

If you want to send 100 emails after your marketing staff clicks the "Send" button on a "marketing" form, you could simply do it inside the request processing pipeline. But it is bad, because this task can and will take too much time. During this time, your user will see the loading indicator. And the user will be more annoyed with every minute. Interrupts due to time out? IIS can! And when half of the letters were sent, it is hard to determine what to do next.

Next simple way is to create a background thread that runs within ASP.NET process. User clicks the "Send" button, then the newsletter sending job is being marshalled to a background thread. That thread performs the job in the background, and your system is able to quickly answer to the user. Bam! Your application was abnormally terminated, or you are just deploying a new version and the thread was aborted. Some emails were not sent. What to do? Or what to do when your SMTP server goes down?

So, you are beginning to use some sort of persistence. Perhaps, you are beginning to build a job queue. Perhaps, using NServiceBus as your framework. With the persisted job queue you are able to see, what jobs are still undone and do only them. It provides you with some sort of reliability, because outages will not harm your system. Also you can put the failed job back to the queue to retry it later. Plus, you can plug more background threads (or worker) to process enqueued jobs. But truly reliable processing requires some more things to be done, especially if you storage is in the separate process on a separate computer.

Job queues also helps you to move the background processing outside of your ASP.NET application. App now acts as a Client, that puts jobs on a Queue, and different process acts as a Processing Server. So, your background tasks continue to work while you are changing web.config parameters in your app.

HangFire is not an alternative for NServiceBus. It just defines the way to perform some methods in the background in a reliable way. You can start with a simple, in-process processing and you are able to scale it when your application became more popular without any pain. The way how HangFire implemented is being used in a different set of project, like Sidekiq, Resque, delayed_job. They are running on a Ruby platform and are used by many companies, including GitHub. These projects are great, and I wanted to see them in the .NET environment.

NServiceBus is an implementation of a service bus architectural pattern, that applies to distributed environments. It describes the way your application talk with each other in a generic way using messages and message queues. It is generic, but very complex. And you can build different systems and different things with it, including background processing system, but you must think about every process in your processing system manually.

You can also check the following article of the author of the similar system to HangFire, but for Ruby: http://www.mikeperham.com/2011/05/04/background-processing-vs-message-queueing/

from hangfire.

man, what can i say, you took all this time to answer me questions, i really dont know how to say thank you :)
you have cleared many issues for me.

i really cant wait for the Docs to be done, all the best man and thanks again for the time you spent on answering me.

from hangfire.