mikasjp

I’m not entirely sure what the practical advantage of that approach would be compared to the explicit semaphore, but I’d be happy to learn more. If you think it’s a better solution, you’re more than welcome to open a pull request

Under the hood, BusyBee consists of an in-memory queue built on Channels and a job processor that dequeues and executes tasks. The processor is essentially a BackgroundService, but BusyBee wires everything together for you, so you don’t have to manually set up the queue, parallel processing, timeouts and errors handling and observability for OpenTelemetry.

It is a thin abstraction over Channels, and that’s by design. What it adds is graceful shutdown handling, OpenTelemetry integration, timeout support, and simple configuration. I kept needing those pieces in almost every project, so wrapping them up into a small reusable library felt worthwhile.

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.

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.

BusyBee 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.

I think the whole problem is keeping the character encoding consistent in the applications and their dependencies. Programmers often forget this because they avoid non-ASCII characters in their code.

I am a full time .NET developer, but I have been interested in Ruby for some time. Not very professional, but I liked this technology very much. I would like to share why I think so.

Today I encountered an interesting case. I got a report that “something changes the date format while processing data”. I started debugging our distributed system looking for the source of the problem. It took me a while, so I’d like to share this story today, so you don’t have to waste your time.