Fast and observable background job processing for .NET
1–10 of 26 posts
Re: Fast and observable background job processing for .NET
#2BusyBee is a high-performance .NET background processing library built on native channels. It provides a simple, configurable, and observable solution for handling background tasks with built-in OpenTelemetry support and flexible queue management.
Re: Fast and observable background job processing for .NET
#3How is it different from hangfire?
Re: Fast and observable background job processing for .NET
#4I'm trying to find the actual value-add here. This feels like TPL but with more steps.
Why do we need to serialize the jobs through a Channel? Couldn't we just do Task.Run and let the runtime take care of scheduling our work?
Re: Fast and observable background job processing for .NET
#5This seems to be a thin abstraction over Channels, I'd probably prefer to use Channels directly in almost all cases.
I really like Channels for in-memory queues like this, they're very nice and it's easy to make everything parallel. But if you need more than this you usually need persistence, and then you need something else entirely.
Re: Fast and observable background job processing for .NET
#6I'm trying to find the actual value-add here. This feels like TPL but with more steps. Why do we need to serialize the jobs through a Channel ? Couldn't we just do Task.Run and let the runtime take care of scheduling our work?
I wish TPL Dataflow was more known.
Re: Fast and observable background job processing for .NET
#7I'm trying to find the actual value-add here. This feels like TPL but with more steps. Why do we need to serialize the jobs through a Channel ? Couldn't we just do Task.Run and let the runtime take care of scheduling our work?
You have no control over concurrency/scheduling, have to manage scoping, error handling, etc. TPL/Threads add to much low level noise to the logic.
Like you could easily blow up the thread pool depending on what you are doing, where a channel based implementation would just deal with spillover and not affect the other threads. You can easily capture scoped services that are disposed by the time the thread executes - but you never catch it in dev because you get executed immediately and request takes long enough, etc.
Spawning threads will work but I can see the use in a small abstraction like this lib for sure. Not sure I would use a lib for this - would probably hand roll something since I don't like adding unvetted external deps by default.
Re: Fast and observable background job processing for .NET
#8I'm trying to find the actual value-add here. This feels like TPL but with more steps. Why do we need to serialize the jobs through a Channel ? Couldn't we just do Task.Run and let the runtime take care of scheduling our work?
You have no control over concurrency/scheduling, have to manage scoping, error handling, etc. TPL/Threads add to much low level noise to the logic. Like you could easily blow up the thread pool depending on what you are doing, where a channel based implementation would just deal with spillover and not affect the other threads. You can easily capture scoped services that are disposed by the time the thread executes -…
Channels are a built-in feature from Microsoft, and they do all the hard work here.
Re: Fast and observable background job processing for .NET
#9How is it different from hangfire?
Hangfire is primarily a job scheduler. It is designed for running jobs at specific times or intervals, and it persists jobs in a database so they survive restarts. It comes with a dashboard, retries, and a lot of infrastructure around long‑term job management. That makes it powerful, but also heavier in terms of setup and overhead.
BusyBee is focused on lightweight background processing. Everything is in‑memory, with no external storage required. It is designed for scenarios where you want to enqueue a task and have it executed immediately in the background, without scheduling or persistence.
A practical example: if you are building an API that accepts file uploads and you want to process the file asynchronously after the request returns, BusyBee is a good fit. You just enqueue the job and it runs in the background right away. If instead you need to schedule a nightly cleanup job or ensure jobs survive application restarts, Hangfire would be the better choice.
Re: Fast and observable background job processing for .NET
#10Earlier quoted context omitted.
You have no control over concurrency/scheduling, have to manage scoping, error handling, etc. TPL/Threads add to much low level noise to the logic. Like you could easily blow up the thread pool depending on what you are doing, where a channel based implementation would just deal with spillover and not affect the other threads. You can easily capture scoped services that are disposed by the time the thread executes -…
Channels are a built-in feature from Microsoft, and they do all the hard work here.
Yeah thats what I am saying - I would just hand roll my background worker with channels probably