![]() Hangfire ships with a built-in UIDashboard to show a graph of job historyList of recurring jobsView job historyJobs can be manually startedList of servers.It's similar to how you would scale session with ASPNETAs you scale out your asp.net application, hangfire will scale with itIF YOU WANT, you can also deploy servers individuallyHangfire is NOT coupled to asp.net, it can run in a console app or windows service tooFor Job Storage, default hangfire uses SQL ServerBUT there are extensions to use other databases for job storageThis is where Couchbase can come in, provide faster access to job data AND can easily scale horizontally for massive job processing.And by the way Couchbase can handle session storage, caching, user profile, etc. The way it scales is going to look familiar to many of you.The client and server can be in the same application.This is the elevator pitch for hangfireIt addresses the drawbacks of the other methodsAnd carves out its own niche in background processingEasy to get started for simple tasks, easy to scale for handling a lot of them.May require implemented specific interfaces, base classes, APIs, that require some coupling.Again, for good reason, because these are often meant to support complex scenarios, multiple-state background processing, long running multi-step processes, broadcasting, etc. Rabbit and Kafka require deployments of their own, the others might as well. There's lot of monitoring tools and ecosystems around these.These are fine tools, and I can't tell you that you shouldn't use them either!But these are relatively heavy solutions. Another approach is to use a message broker, a queueing system, a service bus, the actor model, pub/sub, etcThese are tools that are meant to pass messages around between processes and/or distribute work amongst multiple nodes/worker processesAnd once again, these are fine pieces of software being used to great effect.These tools all have state, so they're able to do things like retries.It can't do fire-and-forget, continuations, retries, etc by itself So I can't possibly say that you shouldn't use cron or schedulerBut the issue is that it will typically require a separate process to be created/deployed, which can complicate your deploymentYou could have cron just hit an HTTP endpoint in your ASP.NET application, but this could tie up HTTP and even a dirt simple script like "cron curl" is still a separate thing that has to be remembered, deployed, updated, separately from your asp.net appAlso, with cron, it's just a scheduler, it has no state. Time based job scheduling"cron" is a unix commandIn windows the equivalent is a "scheduled task"Cloud providers have similar capabilities: Azure Scheduler, AWS Scheduled Tasks, and so onCron itself has a specific syntax, but often when people say "cron job" they mean "execute some process on a schedule"Cron is tried and true and stands the test of time, possibly one of the best pieces of software ever created.Stack Overflow question about threading, it's about threading, but I think it's relevant when it comes to background processingJust celebrated the 10 year anniversary of this sarcastic, worthless, but accepted answer.Non-cron: Complex/heavy setup/deployment."I am not an expert, but I am an enthusiast." – Alan Stevens. ![]() Background Tasks Without a Separate Service: Hangfire for ASP.NET - KCDC - July 2019
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |