WJb Docs - Intermediate
Learn workflows, persistence, scheduling, and production-ready patterns.
π Start Here
π§© Mental Model
π Building Workflows
π₯ Failures & Control
π Observation & Debugging
π Practical Patterns
β Working Examples
β‘οΈ Whatβs Next
π Explicit vs Hidden
WJb is designed around one clear distinction:
Explicit transitions versus Hidden transitions.
Hidden Approach (Typical Systems)
In many background job frameworks the flow looks like this:
Job
β
Pipeline
β
Middleware
β
Filters
β
Retry Policy
β
Continuation (configured somewhere)
Problems:
- Workflow logic is scattered
- Next steps are often defined outside the code
- Debugging requires understanding framework internals
- It is hard to answer βwhat runs next?β by reading one place
Explicit Approach (WJb)
WJb keeps everything visible:
Action
β
IActionResult
β
JobCommand
β
Next Job
The action itself decides the next step:
return await NextAsync<LogAction>(
new LogInput { Message = "Email sent" });
Or finishes the workflow:
return await CompleteAsync();
No hidden pipelines. No external workflow definition. No magic.
Side-by-Side Comparison
| Aspect | Hidden Systems | WJb (Explicit) | |---------------------|-----------------------------|---------------------------------| | Next step | Config / Middleware | Returned from the action | | Workflow definition | Often external | Pure C# code | | Debugging | Framework knowledge needed | Read the action | | Testing | Harder | Straightforward | | Visibility | Low | High |
Concrete Example
Hidden style (conceptual)
// Somewhere in configuration or attributes
[ContinueWith("LogAction")]
public class SendEmailAction { ... }
Explicit style (WJb)
public override async Task<IActionResult> ExecuteAsync(
EmailInput input, CancellationToken ct)
{
// send email...
return await NextAsync<LogAction>(
new LogInput { Message = "Email sent" });
}
The decision lives in the same method that performs the work.
Why Explicit Wins
- You always know where the workflow logic is
- Changes are localized
- Code reviews catch workflow mistakes early
- New team members understand the flow quickly
- No surprises at runtime
The Rule
If the next step is not visible when you read the action, the workflow is not explicit enough.
WJb forces the workflow to stay visible.