WJb 0.113.2

⚡ WJb

If you can't explain why a job runs, you don't control your system.

Most background job systems eventually become:

Job
 ↓
Retry
 ↓
Pipeline
 ↓
Middleware
 ↓
???

Then somebody asks:

• Why did this run?
• Why was it retried?
• Who scheduled the next step?
• Where is that logic?

And nobody can answer in 30 seconds.

WJb

WJb is an explicit background job engine for .NET.

Job
 ↓
Action
 ↓
ActionResult
 ↓
JobCommand

Every step is visible.

Every transition is explicit.

Every workflow is defined in code.

Example

Workflow:

send-email
      ↓
log
      ↓
done

public sealed class SendEmailAction : JobAction<EmailInput>
{
    public override Task<ActionResult> ExecuteAsync(EmailInput input, CancellationToken ct)
    {
        return Task.FromResult(ActionResults.Next(
            new JobCommand("log", new LogInput
            {
                Message = $"Email sent to {input.To}"
            })));
    }
}

public sealed class LogAction : JobAction<LogInput>
{
    public override Task<ActionResult> ExecuteAsync(LogInput input, CancellationToken ct)
    {
        Console.WriteLine(input.Message);

        return Task.FromResult(ActionResults.None());
    }
}

The workflow is not hidden.

The action decides what happens next.

Blazor WebAssembly

WJb can run entirely inside a Blazor WebAssembly application.

builder.Services.AddSingleton<IWJb>(...);
builder.Services.AddSingleton<WasmWorker>();

var app = builder.Build();

app.Services
    .GetRequiredService<WasmWorker>()
    .Start();

await app.RunAsync();

The worker supports:

• Signal-based wake-up
• Configurable polling fallback
• Signal-only mode
• No ASP.NET Core Hosting dependency

Performance

WJb is designed to minimize overhead and unnecessary abstractions.

Benchmarks:

👉 https://github.com/UkrGuru/WJb.Demo/tree/main/benchmark

Quick Start

var store = new InMemoryStore();

var wjb = WJbBuilder.Create(
    store,
    cfg =>
    {
        cfg.AddAction<SendEmailAction>("send-email");
        cfg.AddAction<LogAction>("log");
    });

await wjb.EnqueueAsync(
    "send-email",
    new EmailInput
    {
        To = "user@test.com"
    });

await wjb.ExecuteLoopAsync();

Large Payloads

WJb supports large payloads, but jobs should generally remain small.

Preferred:

var bodyId = await storage.SaveAsync(
    htmlStream,
    ".html");

await wjb.EnqueueAsync(
    "send-email",
    new
    {
        To = "user@test.com",
        Subject = "Monthly report",
        Body = bodyId
    });

Instead of:

await wjb.EnqueueAsync(
    "send-email",
    new
    {
        To = "user@test.com",
        Subject = "Monthly report",
        Body = hugeHtmlString
    });

WJb does not automatically pack or unpack data.

Store    = Jobs

Storage  = Large Content

Action   = Decides When Storage Is Used

What Makes WJb Different?

✅ Explicit workflows

✅ Explicit retries

✅ Explicit next-step scheduling

✅ Constructor injection

✅ Strongly typed actions

✅ Business logic in code

✅ Blazor WebAssembly support

✅ No Hosting dependency required

❌ Hidden pipelines

❌ Hidden orchestration

❌ Workflow magic

Mental Model

Action       = Business Logic

ActionResult = Outcome

JobCommand   = Next Step

Executor     = Runner

Store        = Persistence

That's it.

Packages

Use WJb If

You want to answer all of these immediately:

• Why did this job run?
• What did it do?
• What will run next?
• Why was it retried?

Support

📧 ukrguru@gmail.com

☕ https://ko-fi.com/ukrguru

Background jobs shouldn't be magic.