DEV Community

Cover image for WJb: Explicit Background Jobs for .NET (Near v1.0)
Oleksandr Viktor
Oleksandr Viktor

Posted on

WJb: Explicit Background Jobs for .NET (Near v1.0)

#ai #webdev #programming #productivity

WJb: Explicit Background Jobs for .NET (Near v1.0)

Background processing in .NET often starts simple — and quietly becomes complex.

Retries appear where you did not expect them.

Execution happens “somewhere in the background”.

Workflows grow implicit behavior few people fully understand.

WJb was created as a response to that drift.

As the project approaches v1.0, this article explains what WJb is, what it deliberately is not, and why its design looks different from most background job frameworks.

The Problem WJb Tries to Solve

Many background job frameworks optimize for convenience:

  • automatic retries
  • implicit pipelines
  • hidden orchestration
  • dynamic runtime behavior

These features are useful — until background execution becomes core business logic.

At that point, questions become difficult to answer:

  • Why did this job run?
  • Why did it retry?
  • What state did it operate on?
  • What decides the next step?

WJb takes a different stance:

If background jobs are part of your domain, their behavior must be explicit and predictable.

Core Design Principles

WJb is built around a small number of firm rules.

1. Queue‑First, Always

Nothing executes immediately.

Every unit of work:

  • is serialized into a job payload
  • enters a queue explicitly
  • is processed later by a worker

This establishes a hard boundary between intent and execution.

request work → enqueue → execute later
Enter fullscreen mode Exit fullscreen mode

No method call ever causes hidden execution.

2. Explicit Execution Model

WJb does not provide:

  • automatic retries
  • implicit continuation
  • background pipelines
  • workflow engines

If a job continues, it does so because code explicitly enqueued the next job.

await jobs.EnqueueJobAsync(nextJob);
Enter fullscreen mode Exit fullscreen mode

Routing belongs to actions, not infrastructure.

3. Immutable Snapshots

Execution in WJb operates on immutable snapshots:

  • action registries are built deterministically
  • snapshots are replaced atomically
  • readers never observe partial state

This model avoids synchronization complexity and makes reasoning about concurrency trivial.

4. Actions Own Their Lifecycle

In WJb:

  • infrastructure executes
  • domain code decides

Actions:

  • read metadata
  • perform work
  • optionally enqueue the next job

Infrastructure never orchestrates workflows or interprets intent.

A Minimal Example 

var job = await jobs.CompactAsync(
    "hello",
    new { name = "World" });

await jobs.EnqueueJobAsync(job);
Enter fullscreen mode Exit fullscreen mode

That is all it takes to enqueue work.

Execution happens:

  • when the host starts
  • when the processor consumes the queue
  • with no hidden steps

Workflow Example (Explicit by Design) 

fib-start → fib-build
Enter fullscreen mode Exit fullscreen mode

The continuation is not implicit.

The first action decides explicitly:

await jobs.EnqueueJobAsync(nextJob);
Enter fullscreen mode Exit fullscreen mode

No framework magic.

No pipeline inference.

No hidden guarantees.

Performance Without Tricks

Despite its explicit design, WJb is fast — very fast.

Recent baseline benchmarks (Free edition):

  • ~830k jobs/sec single‑thread enqueue
  • ~1.9M jobs/sec multi‑thread enqueue (20 threads)
  • ✅ strict FIFO within priority
  • ✅ strict priority precedence

These numbers come without unsafe code, without custom schedulers, and without sacrificing correctness.

Performance is a natural outcome of the architecture — not a special optimization step.

What WJb Intentionally Does Not Do

WJb is not trying to replace everything.

It deliberately avoids:

  • delivery guarantees
  • persistent storage by default
  • retries or backoff strategies
  • distributed coordination
  • dynamic workflow engines

These concerns belong either:

  • to hosting infrastructure
  • or to explicit domain code

WJb’s job is to remain transparent and predictable.

Free Edition Today, v1.0 Tomorrow

As of v0.29, the Free API is frozen.

That means:

  • public contracts are stable
  • documented behavior matches runtime behavior
  • samples and tests reflect real execution

The next step toward v1.0 is real‑world usage, not feature expansion.

v1.0 will not mean “more features”.

It will mean confidence.

Who WJb Is For

WJb is for engineers who:

  • design long‑living systems
  • operate production infrastructure
  • value explicit behavior over automation
  • want background code to behave like foreground code

If convenience tooling worked for your case — keep using it.

If you ever said “I want to see exactly what happens” — WJb may be for you.

Closing Thoughts

WJb does not try to be clever.

It tries to be honest.

Honest about:

  • when work runs
  • why it runs
  • what state it sees
  • and what happens next

As the project moves toward v1.0, that principle remains unchanged.

Repository:

👉 https://github.com/UkrGuru/WJb

Top comments (0)