Flow Studio
Workflow Nodes vs. Server-Side Nodes
The two fundamental node execution patterns in the Flow Studio platform — and the architectural decision framework for choosing between them.
The Core Distinction
Every executable node in a flow belongs to one of two patterns. The pattern determines how the node is hosted, how its state is managed, and how it participates in a workflow execution.
| Dimension | Standard Workflow Node | Server-Side Node |
|---|---|---|
| Lifetime | Lives only for the duration of one node execution (milliseconds to seconds) | Runs as a daemon for the lifetime of the application process |
| State | Stateless — no memory between invocations | Stateful — maintains connections, caches, loaded models between calls |
| Instantiation | One instance per execution (DI scope) | One shared instance (singleton hosted service) |
| Startup cost | Near-zero — DI resolution only | Paid once at process startup (model loading, connection pool init) |
| Interface | IProcessElementExecution.ExecuteAsync | IServerNode.HandleRequestAsync + IHostedService |
| Called by | Workflow engine directly | Workflow engine via ServerNodeCallExecutor |
Pattern Overview
Standard Workflow Node (per-execution)
────────────────────────────────────────
WorkflowEngine
│ ExecuteAsync(ctx)
▼
StandardNodeExecutor ← short-lived, scoped DI
│
▼
NodeExecutionResult ← result stored in execution context
Server-Side Node (always-on)
────────────────────────────────────────
ApplicationHost (IHostedService)
├── ModelLoaded, ConnectionsInitialised
└── IServerNode registered in ServerNodeRegistry
WorkflowEngine
│ ExecuteAsync(ctx)
▼
ServerNodeCallExecutor ← standard node that routes to server node
│
▼
ServerNodeRegistry.Resolve(nodeId)
│
▼
IServerNode.HandleRequestAsync(request)
│
▼
NodeExecutionResult
Choosing a Pattern
The decision comes down to three questions:
- Is startup cost significant? (model loading, connection pool warmup) → Server node
- Is shared state needed across concurrent calls? (in-memory cache, open socket, streaming session) → Server node
- Is the operation independent and stateless per call? → Standard workflow node
When in doubt, start standard: Standard workflow nodes are simpler to implement, test, and reason about. Only adopt the server node pattern when profiling shows startup cost is a bottleneck or shared state is genuinely required.