HangFire – Reliable and transparent background job processing for ASP.NET | Hacker News Reader

HangFire – Reliable and transparent background job processing for ASP.NET

hangfire.io

31 pointsodinserj13 comments

This post could not have come at a better time! I literally spent the better part of yesterday researching best practices for queueing jobs from ASP.NET (WEB API) hosted on Windows Server, not Azure. I was considering NetMSMQ based WCF, Windows Service Bus 1.1, NServiceBus, MassTransit, ServiceStack, Windows Azure Pack, Redis or RabbitMQ hosting Worker Processes as Windows Services.

I had settled on the later as I wanted to avoid the complicated configuration of WCF, if possible, and just wanted a simple, reliable, and scalable way, to queue messages and process them. Ideally, I wanted a way to host/launch the worker processes from the web app to avoid complicating the development environment by having to install and run separate processes (Windows Service).

I will definitely be looking at this project today and putting it through a PoC.

Update: Forgot to mention ServiceStack in list of frameworks considered.

You will inevitably end up with a separate Windows service, mainly for maintanability reasons.

I would love it if you would elaborate on this thought. Are you referring specifically to a solution build with Hangfire or any solution involving worker processes on Windows?

Why?

I wonder how does it compare to Quartz.NET in terms of functionalities, reliability and scalability ? Has anyone used hangfire in production?

Quartz.NET is built around a scheduler, HangFire is built on top of message queues. If you want to off-load a task from the request processing pipeline, message queue is more preferable solution, because it can greatly reduce the latency of background job processing.

I don't understand why polskibus comment is dead, has I had the same question. I wonder how does it compare to Quartz.NET ?

How is this any different than using MSMQ?

Well, it looks like it might run inside Mono, for one.

So something like RabbitMQ would do exactly the same.

I didn't try to do so, but there is nothing to prevent HangFire to run on Mono. I also consider to support OWIN instead of System.Web for HangFire Dashboard, so Linux and MacOS will be supported.

MSMQ is a colossal PITA to set up. As is RabbitMQ, etc.

I've wanted something like this for a very long time.

HangFire provides you a unified programming model for background job processing on shared, dedicated and cloud hosting. It takes the complexity of background processing itself and lets you to concentrate only on background jobs.

Reply on news.ycombinator.com