Tutorial: Explicit Dependencies First
Start with plain function arguments and interfaces before introducing an environment.
These tutorials provide step-by-step setups for the dependency and runtime patterns that show up most often in real FsFlow applications.
| Tutorial | Focus | Best For |
|---|---|---|
| Explicit Dependencies First | Plain function arguments | The first step: prove your interfaces and workflow shape before introducing an environment. |
| App Record | Concrete environment records | Features that now need several dependencies but still want direct, low-ceremony field access. |
| Runtime Operations | Timeout, retry, cancellation, annotations | Operational boundaries around a workflow execution. |
| Using Existing Services | Standard FsFlow service packages | Apps that want built-in clock, logging, or environment-variable services in an explicit env. |
| Creating Reusable Services | Named service contracts | Shared helpers that should depend on IHas<'service> instead of one record field name. |
| Layers | Provisioned environments and resource ownership | Apps that need startup construction, cleanup, provisioning failure, or scope-owned resources. |
If you are new to FsFlow, start with Explicit Dependencies First, then move to App Record.
Start with plain function arguments and interfaces before introducing an environment.
Move from explicit dependency parameters to a reusable environment record.
Timeout, retry, cancellation, and runtime annotations.
Consume the standard FsFlow service packages from an explicit environment.
Define your own named service contracts and consume them through IHas and Service.get.
Provision environments, manage resources, and keep startup concerns out of workflow code.