WJb 0.117.2
dotnet add package WJb --version 0.117.2
NuGet\Install-Package WJb -Version 0.117.2
<PackageReference Include="WJb" Version="0.117.2" />
<PackageVersion Include="WJb" Version="0.117.2" />
<PackageReference Include="WJb" />
paket add WJb --version 0.117.2
#r "nuget: WJb, 0.117.2"
#:package WJb@0.117.2
#addin nuget:?package=WJb&version=0.117.2
#tool nuget:?package=WJb&version=0.117.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
↓
IActionResult
↓
JobCommand
Every step is visible.
Every transition is explicit.
Every workflow is defined in code.
Simple by Default
Most job systems expose job states.
WJb exposes execution flow.
Enqueue
↓
Dequeue
↓
Complete
The action decides what happens next.
The store records what happened.
Example
public sealed class SendEmailAction : JobAction<EmailInput>
{
public override Task<IActionResult> ExecuteAsync(
EmailInput input, CancellationToken ct)
{
return NextAsync<LogAction>(
new LogInput
{
Message = $"Email sent to {input.To}"
});
}
}
public sealed class LogAction : JobAction<LogInput>
{
public override Task<IActionResult> ExecuteAsync(
LogInput input, CancellationToken ct)
{
Console.WriteLine(input.Message);
return CompleteAsync();
}
}
Action Results
return CompleteAsync();
Complete the current job.
return CompleteAsync(customer);
Complete the current job and save a result.
return NextAsync<SendEmailAction>(
new EmailInput
{
To = "john@example.com"
});
Schedule the next workflow step.
Failures are represented by exceptions:
throw new InvalidOperationException(
"SMTP server unavailable.");
Mental Model
Action = Business Logic
Results = Outcome
JobCommand = Next Step
Executor = Runner
Store = Persistence
That's it.
Packages
| Package | Description |
|---|---|
| WJb | Explicit background job engine |
| WJb.UI.Blazor | Monitoring and administration UI |
| WJb.Sql | SQL Server storage provider (commercial edition) |
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?
- When did it start?
- When did it finish?
Support
📧 ukrguru@gmail.com
Background jobs should be explicit.
If a workflow exists, you should be able to read it.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- No dependencies.
NuGet packages (1)
Showing the top 1 NuGet packages that depend on WJb:
| Package | Downloads |
|---|---|
|
WJb.UI.Blazor
Free Blazor monitoring and administration UI for WJb. Includes jobs monitoring, actions management, services configuration, payload inspection and action testing. |
GitHub repositories
This package is not used by any popular GitHub repositories.
Simplified action pipeline architecture.
Added IAction<TInput> for strongly typed action execution.
Introduced CompleteResult and NextResult workflow results.
Added JobCommand and JobCommand<TAction> with payload support.
Added ActionNameAttribute for custom action names.
Added JobCommands and Results factory helpers.
Improved test coverage across action, command, result, and attribute APIs.