DEV Community: Oleksandr Viktor

WJb Resilient Actions: Designing Fault-Tolerant Background Jobs

Oleksandr Viktor — Fri, 16 Oct 2026 06:02:19 +0000

Resilient Actions

One night, Cron was generating jobs as expected. The queue was accepting them as expected. The Worker was running as expected.

Then a single Action got stuck.

As a result:

Cron continued generating new jobs;
the queue continued growing;
other Actions stopped executing;
the issue was resolved only after a restart.

This is a classic example of how system reliability is determined not by how it behaves in a perfect world, but by how it handles failures.

An Action Must Be Designed for Failure

Every Action operates in a hostile environment:

the network may stop responding;
the database may become slow;
an external API may hang;
the server may restart;
the action may be cancelled by the user.

For this reason, an Action should be designed as if failure is inevitable.

Always Use CancellationToken

Bad:

await http.GetStringAsync(url);

Good:

await http.GetStringAsync(url, ct);

Bad:

await Task.Delay(TimeSpan.FromMinutes(5));

Good:

await Task.Delay(TimeSpan.FromMinutes(5), ct);

If an operation does not support cancellation, the Worker cannot stop the Action gracefully.

Always Define Timeouts

Even when a CancellationToken is used.

Bad:

var http = new HttpClient();

Good:

var http = new HttpClient
{
    Timeout = TimeSpan.FromSeconds(30)
};

External resources are not required to respond quickly.

Sometimes they do not respond at all.

Distinguish Timeouts from Cancellations

A timeout and a cancellation are not the same thing.

A timeout usually means:

the operation took too long and may be safe to retry.

A cancellation usually means:

execution was intentionally stopped and should not be retried.

In .NET both situations may appear as a TaskCanceledException.

Example:

try
{
    await http.GetStringAsync(url, ct);
}
catch (TaskCanceledException ex)
    when (ex.InnerException is TimeoutException)
{
    logger.LogWarning("Request timed out");

    throw;
}
catch (OperationCanceledException)
{
    logger.LogInformation("Action was cancelled");

    throw;
}

Without this distinction, logs may show both situations as simple cancellations even though the retry decision is often the opposite.

A timeout is typically a transient failure.

A cancellation is typically an intentional stop request.

Log Execution Stages

Often the most useful log messages are the simplest ones:

ReportProgress(0, "Loading data");

ReportProgress(0, "Downloaded data");

ReportProgress(0, "Saving data");

ReportProgress(0, "Completed");

If an Action gets stuck, the last message immediately identifies where execution stopped.

For example:

Loading data

It becomes obvious that the problem occurred before the database save phase.

Make Actions Idempotent

After a failure, an Action may execute again.

If re-execution creates duplicate data, the system is not resilient.

Bad:

INSERT INTO Tokens (...)

Better:

INSERT ...
WHERE NOT EXISTS (...)

MERGE

UNIQUE INDEX

A repeated execution should be safe.

Do Not Store State in Memory

Bad:

private static int Processed;

The value will be lost after a restart.

Instead, store state in:

a database;
a queue;
a persistent state store.

An Action should survive process restarts.

Break Large Operations into Smaller Actions

Bad:

DownloadAllHistory();
ProcessAllHistory();
SaveAllHistory();

Good:

download
process
aggregate
publish

Smaller Actions are easier to:

cancel;
retry;
troubleshoot.

Verify Behavior After a Timeout

It is not enough to verify that an Action was cancelled.

You must prove that the queue continues to operate.

A good integration test is:

The first job becomes stuck.
A timeout occurs.
The second job executes successfully.
The queue continues processing.

This scenario closely matches real production behavior.

A Practical Rule

Whenever an Action contains an:

await

ask yourself:

What happens if this operation hangs forever?

If the answer is:

Nothing good.

Then the Action is not production-ready yet.

Summary

A simple, resilient Action has six characteristics:

supports CancellationToken;
defines reasonable timeouts;
distinguishes timeouts from cancellations;
logs key execution stages;
is idempotent;
safely handles re-execution.

In an ideal world, failures never happen.

In production, they happen every day.

A good Action is not one that never fails.

A good Action is one after which the system continues to operate. 🚀🐈‍⬛

1M End2End: WJb vs Quartz vs Hangfire

Oleksandr Viktor — Mon, 12 Oct 2026 06:24:05 +0000

Large Scale End-to-End Benchmark

Real-world processing benchmark using:

1,000,000 jobs
1 worker/thread
In-memory storage

Benchmark Environment

.NET 10.0
Windows 11
Intel Core i7-12700K

Workload

public sealed record EchoPayload(int Id, string Name);

Job implementation:

Interlocked.Increment(ref Completed);

Results

Framework	Time	Jobs/sec	Memory
WJb	4.80 sec	208,344	983.72 MB
Quartz.NET	23.84 sec	41,940	1,292.79 MB
Hangfire	299.00 sec	3,344	2,518.56 MB

Throughput

WJb       208,344 jobs/sec
Quartz     41,940 jobs/sec
Hangfire    3,344 jobs/sec

Processing Time

1,000,000 Jobs

WJb          4.80 sec
Quartz      23.84 sec
Hangfire   299.00 sec

Source Code & Reproducibility

The complete large-scale benchmark suite, including all benchmark runners and source code, is available here:

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

Summary

WJb processed 1,000,000 jobs approximately 5× faster than Quartz.NET.
WJb processed 1,000,000 jobs approximately 62× faster than Hangfire.
WJb used approximately 31% less memory than Quartz.NET.
WJb used approximately 61% less memory than Hangfire.

Notes

In-memory storage only.
Single worker/thread for all frameworks.
End-to-end execution includes enqueue, scheduling, execution, and completion.
Results were measured using standalone console applications.

WJb vs Quartz vs Hangfire Benchmarks

Oleksandr Viktor — Sat, 03 Oct 2026 08:07:50 +0000

WJb vs Quartz vs Hangfire Benchmarks

Performance comparison of WJb, Quartz.NET, and Hangfire using validated benchmarks with normalized concurrency (1 worker/thread per framework).

Benchmark Environment

BenchmarkDotNet v0.15.8
.NET 10.0
Windows 11
Intel Core i7-12700K
20 Logical Cores

Scenario

Each framework processes the same payload:

public sealed record EchoPayload(int Id, string Name);

Job implementation:

Interlocked.Increment(ref Completed);

Validation tests verify:

All jobs complete successfully.
Completion counts match expectations.
Enqueue-only benchmarks do not execute jobs.
End-to-end benchmarks execute every job exactly once.

Concurrency Configuration

To ensure an apples-to-apples comparison:

WJb        : 1 worker
Hangfire   : WorkerCount = 1
Quartz.NET : MaxConcurrency = 1

Enqueue Benchmark

Measures only job submission cost.

No workers running.
No job execution.
Clean storage created for every iteration.

Results

JobCount	WJb	Quartz.NET	Hangfire
1	24.12 µs	30.63 µs	379.25 µs
100	330.59 µs	482.30 µs	31.53 ms
1,000	3.68 ms	4.39 ms	233.22 ms
10,000	25.54 ms	33.88 ms	2,381.42 ms

Enqueue Memory Usage

JobCount	WJb	Quartz.NET	Hangfire
1	1.59 KB	4.58 KB	26.19 KB
100	138.1 KB	371.4 KB	2.14 MB
1,000	1.35 MB	3.77 MB	21.41 MB
10,000	13.41 MB	36.24 MB	213.83 MB

End-to-End Benchmark

Measures the complete pipeline:

Enqueue → Schedule → Execute → Complete

Results

JobCount	WJb	Quartz.NET	Hangfire
100	668.6 µs	11.24 ms	40.86 ms
1,000	7.44 ms	26.41 ms	259.72 ms
10,000	39.94 ms	89.09 ms	2,598.00 ms

End-to-End Memory Usage

JobCount	WJb	Quartz.NET	Hangfire
100	235.6 KB	762.9 KB	7.23 MB
1,000	2.37 MB	7.53 MB	71.50 MB
10,000	23.92 MB	70.92 MB	714.67 MB

Notes

In-memory storage only.
Startup and shutdown costs are excluded.
Validation tests are included in the benchmark suite.
Concurrency is normalized across frameworks.
Results reflect lightweight job workloads and framework overhead rather than heavy business logic execution.

Six Months, One Developer, Too Much Coffee

Oleksandr Viktor — Thu, 01 Oct 2026 07:08:14 +0000

Solo Developers Can Still Build Big Things in 2026 🚀

Every few weeks I see a post claiming something like:

"Modern software is too complex for a solo developer."

Or:

"You need funding, a team, product managers, a designer, a DevOps engineer, and at least three weekly meetings to build anything serious."

As a solo developer, I decided to perform a highly scientific experiment.

The experiment lasted six months.

The results were unexpected.

The Beginning

Six months ago, WJb was just an idea.

Not a company.

Not a startup.

Not a venture-backed product.

Just a simple goal:

Build a modern background job and workflow framework for .NET that is easy to use and easy to extend.

Sounds small enough.

Famous last words.

The Feature Expansion Loop

Build Feature
      │
      ▼
 "Wouldn't it be nice..."
      │
      ▼
 Build Another Feature

Six months later, the original idea had evolved into an ecosystem.

WJb Core

             WJb
               │
     ┌─────────┼─────────┐
     ▼         ▼         ▼
   Actions   Jobs     Workflows

Today WJb provides:

Background jobs
Delayed execution
Scheduled jobs
Recurring jobs
Workflows
Action pipelines
Queues
Retry handling
Progress reporting
Dependency Injection integration

NuGet Packages:

https://www.nuget.org/packages?q=wjb

WJb.UI.Blazor

┌──────────────────────────────┐
│ Dashboard                    │
├──────────────────────────────┤
│ ✅ Completed                 │
│ 🟡 Running                   │
│ ❌ Failed                    │
│ 🔄 Retrying                  │
└──────────────────────────────┘

The dashboard brings visibility to jobs, queues, workflows, progress, payloads, errors, and execution history.

All inside the .NET ecosystem.

Just Blazor.

Supporting Real Projects Means Supporting Real Databases

✅ IndexedDB
✅ SQLite
✅ SQL Server
✅ PostgreSQL
✅ MySQL

This means WJb can be used in:

Blazor WebAssembly applications
Desktop applications
Small services
Enterprise systems
Cloud environments
Self-hosted deployments

Documentation Is a Feature

      Code
        │
        ▼
     Examples
        │
        ▼
 Documentation
        │
        ▼
      Demos
        │
        ▼
      wjb.pro

Website:

👉 https://wjb.pro

The site contains documentation, getting-started guides, examples, and interactive demos.

Testing: Conversations With Future Me

Past Me:
"This implementation is perfect."

Future Me:
"What is this?"

Then you check Git history.

Author: You.

Awkward.

That's why a large amount of effort went into unit tests, integration tests, regression tests, and benchmarks.

Modern Solo Development

           💡 Idea
              │
              ▼
       Alexander
              │
              ▼
        "Let's build it"
              │
              ▼
         Copilot/Grok
              │
              ▼
       Lots Of Code
              │
              ▼
            WJb 🚀

AI doesn't replace developers.

It helps remove friction.

The vision, architecture, debugging, and persistence still come from the developer.

What Six Months Produced

                         WJb
                          │
         ┌────────────────┼────────────────┐
         │                │                │
         ▼                ▼                ▼
      Core           UI.Blazor         Documentation
         │
         ▼
      Providers
         │
 ┌───────┼───────┬───────┬───────┐
 ▼       ▼       ▼       ▼       ▼
IDB   SQLite   SQL   PostgreSQL MySQL

✅ WJb Core

✅ WJb.UI.Blazor

✅ IndexedDB Provider

✅ SQLite Provider

✅ SQL Server Provider

✅ PostgreSQL Provider

✅ MySQL Provider

✅ Documentation

✅ Interactive Demos

✅ Examples

✅ Tests

✅ Benchmarks

✅ NuGet Packages

✅ Website

Useful Links

Website

👉 https://wjb.pro

NuGet Packages

👉 https://www.nuget.org/packages?q=wjb

GitHub

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

Final Thoughts

      One Developer
             +
       Clear Vision
             +
       Modern Tools
             +
         Six Months
             =
      Entire Ecosystem

Six months ago, WJb was just an idea.

Today it includes a framework, a dashboard, multiple providers, documentation, demos, tests, benchmarks, NuGet packages, and a public website.

So the next time someone says:

"A solo developer can't build something serious."

Just smile.

Then ship another release. 🚀

WJb v1.2: From WJb Action to WJb Job

Oleksandr Viktor — Thu, 01 Oct 2026 05:55:25 +0000

WJb v1.2: From WJb Action to WJb Job

Most developers discover WJb through Actions.

An Action is easy to understand.

It is just a class that performs work.

await action.ExecuteAsync(input);

For many scenarios, that is enough.

So why would we introduce Jobs?

Step 1. Execute the Action Directly

Suppose we already have an Action:

[ActionName("send-email")]
public sealed class SendEmailAction
    : JobAction<EmailInput>
{
    public override async ValueTask<ActionResult> ExecuteAsync(
        EmailInput? input,
        CancellationToken ct = default)
    {
        await EmailSdk.SendAsync(input!, ct);

        return ActionResult.Empty;
    }
}

We can execute it directly:

var action = new SendEmailAction();

await action.ExecuteAsync(
    new EmailInput
    {
        To = "john@example.com",
        Subject = "Hello"
    });

The Action runs.

The email is sent.

The work is complete.

For small applications, nothing more is required.

Step 2. The Action Has a Limitation

Imagine the application crashes halfway through processing.

What happened?

Action
 ↓
Execute
 ↓
Crash

Questions immediately appear:

Did the Action start?
Did it finish?
Did it fail?
Should it be retried?

The Action itself does not answer these questions.

An Action performs work.

It does not track work.

Step 3. Introduce a Job

A Job represents a request to execute an Action.

Instead of running:

await action.ExecuteAsync(input);

we create a Job:

var store = new InMemoryStore();

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

await wjb.EnqueueAsync(
    "send-email",
    new EmailInput
    {
        To = "john@example.com",
        Subject = "Hello"
    });

await wjb.ExecuteLoopAsync();

Now something new exists:

Job
 ↓
Action
 ↓
Business Logic

The Job becomes a record of the work.

Step 4. Why Is This Useful?

A Job can answer questions that an Action cannot.

Was it created?
Was it started?
Was it completed?
Did it fail?

The Action still sends the email.

The Job tracks the execution.

Responsibilities become clear:

Action
 ↓
Performs work

Job
 ↓
Tracks work

Step 5. What Actually Changed?

The business logic did not change.

The Action did not change.

Only the execution model changed.

Before:

Application
 ↓
Action
 ↓
Business Logic

After:

Application
 ↓
Job
 ↓
Action
 ↓
Business Logic

The Action remains focused on the task.

The Job adds execution tracking.

Step 6. Build on Top of Jobs

Once work is represented by Jobs, additional capabilities become possible.

Job
 ↓
Retry

Job
 ↓
Scheduling

Job
 ↓
Monitoring

Job
 ↓
Workflows

These features become possible because the execution is now represented by an object that can be stored, queried, and managed.

The Main Idea

An Action answers:

How is the work performed?

A Job answers:

What work should be performed?

The evolution looks like this:

Business Logic
      ↓
Action
      ↓
Job

Job
 ↓
Action
 ↓
ActionResult
 ↓
Step
 ↓
Next Job

Actions execute work.

Jobs represent work.

WJb combines both concepts to make execution reliable, observable, and scalable.

WJb v1.2: From Console Application to WJb Action

Oleksandr Viktor — Wed, 30 Sep 2026 10:50:21 +0000

From Console Application to WJb Action

Most developers do not start with WJb.

They start with a task.

For example:

Send an email.

Before introducing Actions, Jobs, Workflows, or Scheduling, let's solve the problem using plain .NET code.

Step 1. Make It Work

The first goal is not to build a workflow.

The first goal is to solve the problem.

A typical implementation might look like this:

await EmailSdk.SendAsync(
    smtpSettings,
    new EmailInput
    {
        To = "john@example.com",
        Subject = "Test",
        Body = "Hello"
    });

At this point there is no WJb.

Just working code.

The most important rule is:

Make the business logic work before introducing infrastructure.

If the email cannot be sent from a simple application, adding WJb will not fix it.

Step 2. Move the Logic into a Reusable Library

Once the solution works, the next step is usually extracting it into reusable code.

public static class EmailSdk
{
    public static Task SendAsync(
        SmtpSettings settings,
        EmailInput input,
        CancellationToken ct = default)
    {
        // send email
        return Task.CompletedTask;
    }
}

Now the email functionality can be reused from:

console applications;
ASP.NET applications;
worker services;
unit tests.

The business logic is no longer tied to a specific application.

Step 3. Wrap the Library as an Action

Suppose we now want WJb to execute the same operation.

We do not rewrite the email logic.

We simply wrap it inside an Action.

[ActionName("send-email")]
public sealed class SendEmailAction(SmtpSettings smtp)
    : JobAction<EmailInput>
{
    public override async ValueTask<ActionResult> ExecuteAsync(
        EmailInput? input,
        CancellationToken ct = default)
    {
        await EmailSdk.SendAsync(smtp, input!, ct);

        return ActionResult.Empty;
    }
}

Notice what changed.

Before:

await EmailSdk.SendAsync(settings, input);

After:

return ActionResult.Empty;

The business logic remains exactly the same.

The Action becomes a WJb entry point for code that already works.

Step 4. Execute the Action Directly

An Action is still just a class.

You can execute it directly without creating Jobs, Workflows, or Schedules.

var action = new SendEmailAction(smtpSettings);

await action.ExecuteAsync(
    new EmailInput
    {
        To = "john@example.com",
        Subject = "Test",
        Body = "Hello"
    });

At this stage:

no Job is required;
no Workflow is required;
no Scheduler is required;
no Store is required.

You are simply executing an Action.

Step 5. Let WJb Execute It

Once the Action is registered, WJb can execute it on your behalf.

var store = new InMemoryStore();

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

await wjb.EnqueueAsync(
    "send-email",
    new EmailInput
    {
        To = "john@example.com",
        Subject = "Test",
        Body = "Hello"
    });

await wjb.ExecuteLoopAsync();

The flow becomes:

WJb
 ↓
Job (Enqueue)
 ↓
SendEmailAction
 ↓
EmailSdk.SendAsync()
 ↓
ActionResult

The email logic has not changed.

Only the execution model has changed.

The same Action can now be:

executed immediately;
scheduled for later;
retried after failure;
executed on another machine;
included in a workflow via .Next(...).

Example of continuing the workflow:

return ActionResult.Empty
    .Next("log", $"Email sent to {input?.To}");

The Main Idea

Many frameworks require developers to learn the framework before solving the problem.

WJb takes the opposite approach.

Start with working code:

Problem
   ↓
Working Code

Extract reusable business logic:

Problem
   ↓
Working Code
   ↓
Reusable Library

Wrap it as an Action:

Problem
   ↓
Working Code
   ↓
Reusable Library
   ↓
Action

Then let WJb execute it:

Problem
   ↓
Working Code
   ↓
Reusable Library
   ↓
Action
   ↓
WJb Execution

Job
 ↓
Action
 ↓
ActionResult
 ↓
Step
 ↓
Next Job

The business logic remains independent.

WJb does not replace the business logic.

WJb provides a consistent way to execute, schedule, retry, and orchestrate code that already works.

NuGet WJb v1.2 🎉

Oleksandr Viktor — Fri, 11 Sep 2026 19:20:05 +0000

NuGet WJb v0.120 → WJb v1.2 🎉

Behind this single version change are hundreds of hours of development, countless design decisions, testing sessions, bug fixes, and improvements.

Reaching 1.0 doesn't mean the journey is over.

It means the foundation is solid, the vision is clear, and the best is yet to come.

Thank you for being part of the journey.

Welcome to WJb 1.2 🚀

🔗 Website: https://wjb.pro
🔗 GitHub: https://github.com/UkrGuru/WJb.Demo
🔗 NuGet: https://www.nuget.org/packages?q=wjb

🚀 WJb vs Popular Alternatives

Oleksandr Viktor — Tue, 25 Aug 2026 16:02:28 +0000

🚀 WJb vs Popular Alternatives

Over the last months I've been building WJb, a lightweight .NET job and workflow framework focused on simplicity, explicitness, and developer control.

Today, WJb includes:

✅ Background jobs
✅ Delayed execution
✅ Cron scheduling
✅ Workflow chaining
✅ Dependency injection
✅ JSON-based action registration
✅ Strongly typed actions
✅ Pluggable storage

Unlike many alternatives, WJb is designed to work without external infrastructure and without forcing your business logic into framework-specific patterns.

The goal is simple:

Write background jobs as regular C# code and keep full control over how everything works.

How does it compare?

Compared to Hangfire, Quartz.NET, and MassTransit, WJb focuses on:

lightweight deployment
explicit workflows
strongly typed action architecture
low learning curve
no broker requirements
full author control

Is it production ready?

The framework now includes a growing integration test suite covering:

Actions
DI
Scheduling
Storage
Workflows
Results
Queries
Serialization
Extensions

and continues to evolve based on real-world usage.

Looking for early adopters

WJb has reached the point where I'd love to get feedback from other .NET developers.

If you:

use Hangfire,
use Quartz.NET,
built your own background worker,
need lightweight workflows,

please give WJb a try and let me know what works, what doesn't, and what is missing.

Real feedback is far more valuable than assumptions.

🔗 Website: https://wjb.pro
🔗 GitHub: https://github.com/UkrGuru/WJb.Demo
🔗 NuGet: https://www.nuget.org/packages?q=wjb

Your feedback will directly influence the roadmap.

dotnet #csharp #opensource #aspnetcore #backgroundjobs #workflow #hangfire #quartznet #masstransit #nuget #softwarearchitecture #dotnetdev

🚀Nearly 300 Integration Tests Completed

Oleksandr Viktor — Mon, 24 Aug 2026 12:48:51 +0000

🚀 Nearly 300 Integration Tests Completed

Over the past weeks we've been building something that goes beyond traditional unit testing.

WJb now includes nearly 300 integration tests covering real-world scenarios across the entire framework.

These tests validate:

✅ Background Jobs
✅ Workflows
✅ Retries
✅ Scheduling
✅ Monitoring
✅ Storage Providers
✅ SQL Server Persistence
✅ Worker Infrastructure
✅ Action Factories
✅ Configuration & Definitions

But we're taking it one step further.

Every integration test is being transformed into executable documentation, allowing developers to see:

the scenario,
the source code,
the execution result,
and the verified behavior,

all in one place.

📊 Current status:

296 Integration Tests
38 Test Suites
100% Executable Documentation

We're currently publishing the documentation and test explorer here:

👉 https://wjb.pro/tests

More suites will be published over the coming days as we continue converting the entire test suite into browsable documentation.

The goal is simple:

If a feature exists in WJb, it should have a real integration test, and that test should be part of the documentation.

dotnet #csharp #aspnetcore #blazor #opensource #testing #backgroundjobs #workflows #wjb

🚀 Interactive WJB Demos

Oleksandr Viktor — Tue, 18 Aug 2026 18:11:00 +0000

🚀 Interactive WJB Demos

Want to see WJB in action before adding it to your project?

The new interactive demos are now available online:

🔹 Background jobs
🔹 Workflow orchestration
🔹 Scheduling and execution monitoring
🔹 Live examples with source code explanations

Try it now:

👉 https://wjb.pro/demos

WJB is a lightweight .NET library for background jobs and workflows that runs wherever .NET runs, without requiring Redis, message brokers, or external infrastructure.

(#dotnet #csharp #blazor #workflow #backgroundjobs #scheduler #sqlserver #wjb)

⚠️ This article was written during the WJb preview stage. Some APIs have changed since publication. Please refer to the latest documentation:

Website: https://wjb.pro
NuGet: https://www.nuget.org/packages?q=wjb
GitHub: https://github.com/UkrGuru/WJb.Demo

Background Jobs Running Directly Inside Blazor WebAssembly? 🤔

Oleksandr Viktor — Tue, 11 Aug 2026 06:00:13 +0000

Most job frameworks are built for servers.

This demo shows WJb running background jobs entirely in the browser, with real-time progress tracking, status updates, chained actions, and a live dashboard.

✅ Pure Blazor WebAssembly
✅ Real-time progress
✅ Chained workflows
✅ Success / Failure handling
✅ Live demo

🎬 Video:

https://www.youtube.com/shorts/Tu3TD2Rk37E

https://github.com/UkrGuru/WJb.Demo/tree/main/samples/WJb.Demo.Wasm

Would you run job workflows in the browser? What use cases come to mind?

dotnet #csharp #blazor #webassembly #workflow #backgroundjobs #opensource

Running Background Jobs in Blazor WebAssembly with WJb

Oleksandr Viktor — Mon, 10 Aug 2026 17:59:05 +0000

Most background job frameworks are designed for server applications.

As an experiment, I built a demo showing the WJb background job engine running entirely inside a Blazor WebAssembly app. The demo executes jobs in the browser, tracks progress, updates UI in real time, supports chained actions, and demonstrates success, failure, and cancellation scenarios.

Key things demonstrated:

✅ Background job execution in a WASM environment
✅ Real-time progress tracking
✅ Chained actions
✅ Status handling (Completed / Failed)
✅ Live dashboard
✅ Decoupled action architecture
✅ Job cleanup support

One of my goals with WJb is to keep workflows and jobs as regular C# code instead of introducing DSLs, XML, or designers.

Source and demo:

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

I'd be interested to hear from other .NET developers:

Would you ever run a job/workflow engine in the browser, and what use cases would justify it?