DEV Community: Oleksandr Viktor

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?

📚 WJb documentation is finally here.

Oleksandr Viktor — Wed, 05 Aug 2026 19:08:14 +0000

📚 WJb documentation is finally here.

One of the most common challenges for any open-source project is reducing the entry barrier for new users. Today WJb takes a big step forward with a dedicated documentation guide:

https://github.com/UkrGuru/WJb.Demo/blob/main/docs/README.md

The guide covers: • Core concepts
• Workflow structure
• Configuration examples
• Getting started steps
• Practical usage scenarios

Documentation is never as exciting as implementing new features, but it is often more important for project adoption.

Feedback is welcome!

Integration Tests for Background Jobs in ASP.NET Core

Oleksandr Viktor — Tue, 28 Jul 2026 15:21:47 +0000

Integration Tests for Background Jobs in ASP.NET Core

One thing I always look for in job-processing frameworks is real integration testing, not just unit tests.

I put together a sample test suite for WJb that shows how to test background jobs end-to-end using ASP.NET Core's test infrastructure:

🔗 https://github.com/UkrGuru/WJb.Demo/tree/main/test/WJb.IntegrationTests

Highlights:

✅ Test jobs through a real DI container
✅ Verify execution flow and scheduling behavior
✅ Test worker startup and background processing
✅ Keep tests deterministic and easy to understand
✅ No mocking of the framework internals

If you're building background processing solutions in .NET, integration tests like these can catch issues that unit tests often miss.

dotnet #aspnetcore #testing #integrationtesting #backgroundjobs #opensource #csharp #wjb

WJb vs Hangfire vs Quartz: Same Benchmarks, Same Machine

Oleksandr Viktor — Mon, 27 Jul 2026 08:36:07 +0000

WJb vs Hangfire vs Quartz: Same Benchmarks, Same Machine

Background job libraries are usually compared by features.

This benchmark compares something simpler:

How fast can they enqueue work?

Repository:

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

Benchmarks were implemented separately for:

WJb
Hangfire
Quartz

Using:

BenchmarkDotNet
In-memory storage
No-op jobs/actions
Equivalent benchmark scenarios

Single Enqueue

Enqueue one job.

Library	Time	Memory
WJb	349 ns	328 B
Quartz	3.848 μs	3.08 KB
Hangfire	6.212 μs	11.46 KB

Result

WJb ≈ 11× faster than Quartz
WJb ≈ 18× faster than Hangfire

EnqueueMany (100,000 Jobs)

Bulk enqueue benchmark.

Library	Time	Memory
WJb	32 ms	31 MB
Hangfire	743 ms	1063 MB
Quartz	902 ms	539 MB

Result

WJb ≈ 23× faster than Hangfire
WJb ≈ 28× faster than Quartz

Parallel Enqueue (100,000 Jobs)

Multiple concurrent producers.

Library	Best Time
WJb	52 ms
Hangfire	540 ms
Quartz	600 ms

Memory Usage

100,000 jobs:

Library	Memory
WJb	31 MB
Quartz	539 MB
Hangfire	1063 MB

Result

WJb uses ~17× less memory than Quartz
WJb uses ~34× less memory than Hangfire

Why WJb?

WJb was designed around a very small execution model:

enqueue
  ↓
job
  ↓
action

No dashboard.

No workflow engine.

No implicit pipeline.

Just explicit background jobs.

Reproduce

Source code is included:

WJb.Benchmarks
WJb.Benchmarks.Hangfire
WJb.Benchmarks.Quartz

Run:

dotnet run -c Release

Final Numbers

For these benchmark scenarios:

✅ Fastest enqueue: WJb

✅ Fastest bulk enqueue: WJb

✅ Fastest parallel enqueue: WJb

✅ Lowest memory usage: WJb

Benchmark scenarios are intentionally small, reproducible, and focused on enqueue performance.
Additional scenarios will be added only when equivalent implementations exist for all compared libraries.

Why WJb?

Oleksandr Viktor — Thu, 23 Jul 2026 10:13:05 +0000

Why WJb?

WJb is a lightweight workflow engine for .NET that lets you orchestrate business processes using plain C# code.

No DSLs. No XML. No visual designers. No mandatory infrastructure.

Build workflows the same way you build the rest of your application.

Key Advantages

1. Zero Required Dependencies

WJb can be added to almost any .NET application without introducing infrastructure requirements.

You do not need:

SQL Server
PostgreSQL
Redis
RabbitMQ
Kafka
Docker
Kubernetes

Install the package and start building workflows immediately.

2. Works Anywhere .NET Runs

WJb is not tied to a specific hosting model.

Use it in:

ASP.NET Core applications
Console applications
Worker Services
Windows Services
Linux services
Docker containers
Azure-hosted applications
IIS-hosted applications

3. Fast and Simple to Start

Your first workflow can be running within minutes.

There is no need to:

Deploy additional services
Configure message brokers
Learn a workflow-specific language
Set up distributed infrastructure

4. Workflows Are Just C

WJb embraces the language you already use every day.

No:

DSL
XML
YAML
JSON workflow definitions
Visual process designers

Use familiar .NET concepts:

Classes
Interfaces
Dependency Injection
Generics
Async/await

5. Full IDE Support

Because workflows are regular C# code, your IDE understands them completely.

You get:

Go To Definition
Find Usages
Rename Refactoring
Code Navigation
IntelliSense
Debugging
Breakpoints

No special tooling required.

6. Minimal Learning Curve

If you already know:

C#
Dependency Injection
Async programming

you already know most of what is needed to be productive with WJb.

7. Actions Are Simple Classes

Each workflow step is an individual Action.

Benefits:

Clear responsibility
Easy maintenance
Reusability
Better testability
Better readability

8. Readable Business Processes

Large business processes often become scattered across services, controllers, event handlers, and background tasks.

WJb keeps workflow logic organized and visible.

A developer can quickly understand:

Where execution starts
Which steps run
Where decisions are made
How the process ends

9. Reusable Building Blocks

Actions can be reused across multiple workflows.

For example:

Validation actions
API integration actions
Email actions
Database actions

Build once and use everywhere.

10. Easy Unit Testing

Workflows and Actions can be tested independently.

You can test:

Single actions
Action chains
Complete workflows

Without running external infrastructure.

11. Architecture-Friendly

WJb does not force a specific architectural style.

It works well with:

Clean Architecture
Modular Monolith
Vertical Slice Architecture
Layered Architecture
CQRS

WJb complements your architecture instead of replacing it.

12. No Mandatory Message Queues

Many workflow systems assume queues are always required.

WJb does not.

If your solution needs a queue, use one.

If it does not, you can keep your system simple.

13. No Mandatory Database

For simple scenarios, workflows can run entirely in memory.

When persistent state becomes necessary, you can add WJb.Sql without changing your workflow design.

14. Grow at Your Own Pace

A typical adoption path looks like this:

Step 1

Use WJb for workflow orchestration.

Step 2

Add WJb.Sql for persistence and durability.

Step 3

Add WJb.Pro for monitoring and management capabilities.

Start small and expand only when needed.

15. Complete Workflow Visibility

A workflow is defined in one place.

Developers can easily see:

Entry points
Workflow steps
Branches
Error paths
Completion paths

This significantly improves maintainability.

16. Ideal for Long-Running Processes

WJb is a natural fit for workflows such as:

User onboarding
Order processing
Approval flows
Document processing
Data imports
System integrations

17. Small Core, Few Concepts

You do not need to learn an entirely new platform.

The core concepts are intentionally small and focused.

This helps teams become productive quickly.

18. Perfect for Small Teams

Many workflow platforms assume large teams and dedicated infrastructure engineers.

WJb works especially well for:

Solo developers
Small development teams
Startups
Internal business applications

19. Ready for Enterprise Systems

WJb can support workflows behind:

CRM systems
ERP systems
Financial platforms
Document management systems
Integration solutions

Simple enough to start, powerful enough to scale.

20. Stays Inside Your Application

Your workflow engine remains part of your application rather than becoming a separate platform.

Benefits include:

One repository
One deployment pipeline
One testing strategy
One development experience

Everything remains in familiar .NET code.

In One Sentence

WJb lets you build workflows using plain C#, with zero required infrastructure, full IDE support, excellent testability, and a clear upgrade path from simple in-memory workflows to production-grade persistent workflow orchestration.

NuGet Packages:

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

Demo Repository:

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

If You Can't Explain Why a Background Job Runs, You Don't Control Your System

Oleksandr Viktor — Wed, 22 Jul 2026 13:15:50 +0000

Background job systems are everywhere.

Send an email.

Generate a report.

Process a payment.

Synchronize data.

Most applications start simple:

Job
 ↓
Execute
 ↓
Done

Then a few months later:

Job
 ↓
Retry
 ↓
Pipeline
 ↓
Middleware
 ↓
Filters
 ↓
Background magic
 ↓
???

And eventually someone asks:

Why did this job run?

Nobody is quite sure.

Imagine a production incident.

A background job sent thousands of emails.

The logs show success.

The dashboard shows success.

The scheduler shows success.

Yet nobody can answer a simple question:

Why did this job run?

That question became the starting point for my design decisions.

When Execution Becomes Hard to Follow

Modern background processing systems provide powerful abstractions.

The problem is that every abstraction introduces another place where execution flow can hide.

Questions become surprisingly difficult:

Why was this job retried?
What scheduled the next step?
Which component modified execution?
Why did this workflow reach its current state?

The system works.

But understanding the system becomes harder over time.

A Different Approach

While working on workflow and job execution systems, I kept coming back to a simple idea:

Every execution step should be explicit.

Instead of hidden orchestration:

Job
 ↓
Framework
 ↓
Magic
 ↓
Result

I prefer:

Job
 ↓
Executor
 ↓
Action
 ↓
ActionResult
 ↓
JobCommand

Every step is visible.

Every transition is intentional.

Every workflow can be traced by reading code.

Workflows Should Be Code

Consider a simple process:

Send Email
 ↓
Write Log
 ↓
Done

In WJb, an action explicitly decides what happens next.

return ActionResults.Next(
    new JobCommand(
        Actions.Log,
        new LogInput
        {
            Message = $"Email sent to {input.To}"
        }));

The workflow is not hidden in configuration.

The workflow is not hidden in a dashboard.

The workflow is not hidden inside middleware.

It is right there in the action.

Traditional Thinking vs Explicit Execution

Traditional approach:

Job
 ↓
Scheduler
 ↓
Retry Logic
 ↓
Filters
 ↓
Pipeline
 ↓
Result

Explicit execution:

Job
 ↓
Action
 ↓
ActionResult
 ↓
JobCommand
 ↓
Next Action

The difference is not performance.

The difference is understanding what happens when something goes wrong.

What Does a Minimal Workflow Look Like?

send-email → log → done

await wjb.EnqueueAsync(
    Actions.SendEmail,
    new EmailInput
    {
        To = "user@test.com"
    });

await wjb.ExecuteLoopAsync();

The complete example is small enough to understand in a few minutes.

No special DSL.

No separate workflow engine.

No conventions that require documentation to discover.

Explicit Retries

Retries are part of the job configuration.

await wjb.EnqueueAsync(
    RetryAction.Key,
    new EmptyInput(),
    new JobOptions
    {
        MaxRetries = 3,
        RetryDelay = TimeSpan.FromSeconds(10)
    });

Execution flow remains predictable:

Attempt 1
 ↓
Failed
 ↓
Retry Job Created
 ↓
Attempt 2
 ↓
Completed

Nothing mysterious happens behind the scenes.

The Question I Use During Reviews

When reviewing a background processing system, I ask:

Why did this job run?
Who scheduled it?
Why was it retried?
What happens next?

If answering those questions requires opening dashboards, configuration files, middleware registrations and framework internals, the execution model may be more complicated than necessary.

Why I Built WJb

The goal was never to create another scheduler.

The goal was to build a system where you can answer four simple questions:

Why did a job start?
What did it do?
What did it schedule next?
Why was it retried?

If those questions are difficult to answer, debugging production systems becomes harder than it should be.

Predictability First, Performance Second

Predictability was the primary goal.

Performance turned out to be a nice side effect.

Recent BenchmarkDotNet measurements on .NET 10 produced:

CreateOnly       64.9 ns
ExecuteOnly       8.9 ns
CreateAndExecute 75.1 ns

Not bad for a lightweight open source project.

Getting Started

Explore the demo project and examples:

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

Browse all WJb packages:

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

Is WJb Right for You?

WJb may be interesting if you want:

explicit workflows
strongly typed actions
predictable execution
constructor injection
simple orchestration
testable business logic

It may not be the right tool if you prefer:

convention-driven behavior
hidden orchestration
execution pipelines that aren't visible in code

Closing Thoughts

Background jobs should not feel mysterious.

A workflow should be understandable by reading the code that defines it.

That's the principle behind WJb:

Action       = Business Logic
ActionResult = Outcome
JobCommand   = Next Step
Executor     = Runner
Store        = Persistence

You should always know:

why a job started
what it did
what it scheduled next
why it was retried

No magic.

Just explicit execution.

NuGet Packages:

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

Demo Repository:

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

Fresh BenchmarkDotNet numbers for WJb on .NET 10:

Oleksandr Viktor — Sun, 19 Jul 2026 08:30:10 +0000

WJb Core benchmark results:

CreateOnly: 64.9 ns
ExecuteOnly: 8.9 ns
CreateAndExecute: 75.1 ns

At this point, the profiler spends more time blinking than WJb spends executing.

Good luck catching up. 🚀

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

WJb Ecosystem vs Hangfire vs Quartz.NET

Oleksandr Viktor — Sun, 19 Jul 2026 06:30:24 +0000

Why I Would Choose WJb

The .NET ecosystem already has two well-known background processing solutions: Hangfire and Quartz.NET. Both are mature, battle-tested, and widely adopted.

However, the WJb Ecosystem takes a fundamentally different approach.

Instead of focusing solely on scheduling jobs, WJb focuses on building a lightweight, high-performance, and extensible execution platform with a clean separation between execution, storage, hosting, and monitoring.

For many modern .NET applications, this architectural approach can be more valuable than simply having another scheduler.

Quick Summary

Scenario	Recommended Choice
Need a proven solution with a huge ecosystem	Hangfire
Need advanced scheduling and complex cron support	Quartz.NET
Need a lightweight, modern, extensible execution engine	WJb

My personal choice for most new .NET projects would be WJb.

Feature Comparison

Feature	WJb Ecosystem	Hangfire	Quartz.NET
Background Jobs	✅	✅	✅
Delayed Jobs	✅	✅	✅
Recurring Jobs	✅	✅	✅
SQL Storage	✅ WJb.Sql	✅	✅
Monitoring UI	✅ WJb.UI.Blazor	✅ Dashboard	❌ Built separately
Dependency Injection	✅	✅	✅
Extensibility	✅	⚠️	✅
Lightweight Design	✅	❌	❌
Modern .NET Focus	✅	⚠️	⚠️
Learning Curve	✅ Low	✅ Medium	❌ High
Infrastructure Overhead	✅ Low	⚠️ Medium	❌ High

Architectural Comparison

WJb

The WJb ecosystem is built around clear separation of concerns.

WJb
├── Execution
├── Storage
├── Hosting
├── Monitoring UI
└── Extensions

Every layer can evolve independently.

The core engine remains small, understandable, and easy to debug.

Hangfire

Hangfire is built around serialized method execution.

Method Call
    ↓
Serialization
    ↓
Storage
    ↓
State Machine
    ↓
Execution

This model provides excellent convenience but introduces additional infrastructure and internal complexity.

Quartz.NET

Quartz is primarily an enterprise scheduling platform.

Scheduler
    ↓
Trigger
    ↓
Calendar
    ↓
Job Store
    ↓
Job Execution

It is extremely powerful for scheduling scenarios but can feel heavy for many business applications.

What Makes WJb Different

The biggest difference is philosophy.

Hangfire and Quartz were originally designed to answer:

When should work execute?

WJb focuses on:

How should work be executed?

This leads to a cleaner and more flexible architecture.

Why I Prefer WJb Over Hangfire

1. Cleaner Architecture

Hangfire revolves around storing and replaying method invocations.

BackgroundJob.Enqueue(() => SendEmail(id));

This is convenient but tightly couples execution to method serialization.

WJb uses a more explicit execution model.

The result is greater transparency and easier customization.

2. Less Framework Magic

Hangfire contains many internal concepts:

Jobs
Queues
States
Retries
Commands
Continuations
State Machines

While powerful, they require developers to understand Hangfire internals.

WJb exposes a much simpler mental model.

3. Better Separation of Concerns

One of WJb's strongest design decisions is explicit separation between:

Execution
Storage
Hosting
Monitoring

Benefits include:

Easier testing
Easier maintenance
Better extensibility
Lower coupling
Cleaner abstractions

4. Modern Blazor-Based UI

WJb.UI.Blazor provides a modern approach to monitoring and administration.

Advantages include:

Component-based architecture
Easy customization
Native Blazor integration
Rich administration experiences
Consistent .NET development stack

Compared to traditional dashboards, this approach feels more future-oriented.

5. Complete Control

One of the biggest advantages of WJb is visibility.

The framework does not try to hide execution details behind multiple abstraction layers.

Developers maintain control over how jobs are executed, stored, monitored, and extended.

Why I Prefer WJb Over Quartz.NET

1. Lower Complexity

Quartz introduces many concepts:

IScheduler
IJob
ITrigger
Calendar
Listener
JobStore
Misfire Policies

These features are useful but increase complexity significantly.

Most applications never utilize the full capabilities of Quartz.

2. Faster Onboarding

Typical onboarding experience:

Quartz.NET

1-3 days

WJb

1-2 hours

A simpler architecture allows new developers to become productive much faster.

3. Focus on Business Execution

Quartz focuses on scheduling.

WJb focuses on execution.

In many business systems, execution pipelines are more important than complex scheduling rules.

The Ecosystem Advantage

The most interesting aspect is not the core package alone.

It is the ecosystem.

WJb
├── WJb.Sql
├── WJb.UI.Blazor
└── WJb.Pro

This modular structure resembles successful .NET ecosystems such as:

Serilog
MassTransit
Entity Framework

A lightweight core combined with optional modules typically scales much better than a monolithic framework.

Areas Where Hangfire Still Wins

To be fair, Hangfire remains stronger in several areas.

Maturity

Hangfire has:

Many years of production usage
Large community adoption
Extensive documentation
Numerous tutorials
Large ecosystem support

This significantly reduces adoption risk.

Third-Party Integrations

Hangfire offers a very large collection of storage providers and integrations:

SQL Server
PostgreSQL
Redis
MongoDB
Azure Services

Its ecosystem is currently much larger.

Industry Recognition

Most architects and developers immediately recognize:

Hangfire

WJb is still building that brand recognition.

Why I Would Personally Choose WJb Today

Ignoring popularity and focusing purely on architecture, I would choose WJb because of:

Simplicity

Less infrastructure.

Less complexity.

Less maintenance.

Modern Design

WJb feels designed specifically for modern .NET.

Not adapted to it.

Architectural Clarity

The framework makes execution behavior visible and understandable.

Debugging and troubleshooting become significantly easier.

Blazor Administration

WJb.UI.Blazor provides an administration experience that aligns naturally with modern .NET applications.

Growth Potential

WJb currently has many characteristics historically shared by successful infrastructure projects:

Focused
Lightweight
Modern
Fast
Extensible

These qualities often matter more in the long run than initial popularity.

Final Verdict

Hangfire is an excellent background job processor.

Quartz.NET is an excellent scheduler.

WJb Ecosystem is a modern execution platform designed around simplicity, extensibility, and architectural clarity.

If I were starting a new .NET project today and evaluating technology primarily from an engineering perspective, I would most likely choose WJb.

Because in many modern systems:

Simplicity beats complexity.

And WJb achieves that simplicity without sacrificing extensibility.

🚀 New WJb Demo: Workflow Monitoring in Action

Oleksandr Viktor — Sat, 18 Jul 2026 18:09:39 +0000

🚀 New WJb Demo: Workflow Monitoring in Action

Want to see what a complete workflow looks like in WJb?

The new WJb.Demo.Monitor sample demonstrates an end-to-end job pipeline with a live monitoring UI.

✅ Import Customers

✅ Generate Report

✅ Send Email

✅ Monitor execution in real time

Run a single action:

await wjb.EnqueueAsync(
    ImportCustomersAction.Key,
    new ImportCustomersInput
    {
        Source = "CRM"
    });

WJb automatically chains the workflow:

import-customers
        ↓
generate-report
        ↓
send-email

Every step becomes visible in the monitoring dashboard.

What the sample demonstrates

Typed action inputs
Constructor dependency injection
Workflow chaining via IAction.NextAsync(...)
Progress reporting
Background job execution
Real-time monitoring UI
Job payload inspection
Action discovery
Service discovery

Monitor Features

The built-in Blazor monitor provides:

Job status tracking
Progress visualization
Execution history
Payload inspection
Registered actions
Registered services

Why it is interesting

The entire workflow is composed of small focused actions:

import-customers
generate-report
send-email

No workflow designer.

No XML.

No complex configuration.

Just C# actions connected through explicit workflow transitions.

Sample

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

The sample includes:

Workflow execution
Action chaining
Progress reporting
Live monitoring
Payload inspection
Actions explorer
Services explorer

Perfect for understanding how WJb workflows behave in a real application.

🚀 WJb Monitor is coming together.

Oleksandr Viktor — Wed, 15 Jul 2026 16:14:01 +0000

Over the last few days I focused on completing the monitoring UI for WJb.

Current state:

✅ Jobs monitoring
✅ Job details and payload viewer
✅ Actions management
✅ Services management
✅ SQL Store integration
✅ Real job execution testing
✅ Retry and progress tracking
✅ Responsive Blazor UI

A few screenshots are attached, including an animated walkthrough of the application.

One pleasant surprise during development: I completely removed the dependency on Bootstrap Icons. Navigation now uses lightweight SVG icons, while action buttons use simple Unicode symbols. The result is cleaner than expected and has zero external dependencies.

The original plan also included a dashboard page, but after using the application in practice I decided to postpone it. The current feature set already delivers real value, and I'd rather gather experience from actual usage before adding metrics and analytics.

The goal remains unchanged:

🎯 WJb v1.0 Release

Everything is progressing according to plan, and the first stable release is getting very close.

dotnet #csharp #blazor #opensource #softwaredevelopment #jobs #scheduler #microsoft #sqlserver #webdevelopment

🚀 New workflow samples added to WJb Demo (Blazor WASM)

Oleksandr Viktor — Tue, 30 Jun 2026 08:35:11 +0000

🚀 New workflow samples added to WJb Demo (Blazor WASM)

I've just expanded the WJb demo application with two new workflow-focused samples:

✅ Retry Workflow

Automatic retries with JobOptions
Retry delay configuration
Workflow continuation after successful retry
Demonstrates retry inheritance across chained actions

✅ Order Workflow

Multi-step business workflow
CreateOrder → ReserveStock → ChargePayment → SendConfirmation
Progress reporting across workflow steps
Action chaining via ActionResults.Next(...)
Payload propagation between actions

These samples were added while building a new WorkflowTests suite, which also helped uncover and fix several workflow engine issues, including:

Dead-letter infinite loop scenarios
Missing retry policy inheritance for chained actions

The result is a much stronger demonstration of how WJb can be used for real workflow orchestration rather than just background jobs.

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

dotnet #csharp #blazor #opensource #workflow #backgroundjobs #aspnetcore #softwarearchitecture #testing #wasm #wjb #ukrguru