Re:Fast and observable background job processing for .NET
by fabian2k on Wednesday August 20, 2025 @08:18AM
(#44961214)
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
by rafaelmn on Wednesday August 20, 2025 @09:43AM
(#44961885)
Yeah thats what I am saying - I would just hand roll my background worker with channels probably
Re:Fast and observable background job processing for .NET
by mikasjp on Wednesday August 20, 2025 @09:43AM
(#44961886)
This is exactly why I built BusyBee. My team found ourselves hand‑rolling something similar almost every time we started a new project. If we kept needing it, I figured there are probably more people in the same situation. So instead of duplicating the same background queue logic across multiple codebases, I decided to build it once, add proper OpenTelemetry support, and keep it simple without extra bloat. That way we can just reuse it and reduce the amount of similar code we have to maintain.
Re:Fast and observable background job processing for .NET
by bob1029 on Wednesday August 20, 2025 @10:05AM
(#44962098)
> You have no control over concurrency/scheduling
https://learn.microsoft.com/en-us/dotnet/api/system.threadin...
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.