Flow Studio
Decision Framework
A structured set of questions for choosing between the standard workflow node pattern and the server-side node pattern for a new capability.
The Decision Tree
Is the operation's startup cost negligible (< 50ms)?
YES → Standard workflow node
NO ↓
Is startup cost a one-time cost that can be paid at process boot?
YES → Server node (amortise startup cost)
NO → Revisit design (external service? MCP server?)
Does the operation require shared in-memory state across calls?
(e.g., open connection, in-memory cache, loaded model, streaming cursor)
NO → Standard workflow node
YES → Server node (singleton manages shared state)
Is the operation a long-running streaming task that must outlive a single node call?
NO → Standard workflow node
YES → Server node (background task with request queue)
Decision Matrix
| Scenario | Pattern | Reason |
|---|---|---|
| REST API call | Standard | HttpClientFactory pools connections; no startup cost |
| Database query via ADO.NET | Standard | Connection pool managed by driver; executor is stateless |
| MCP tool call | Standard | Client factory manages transports; no local model load |
| Local LLM inference (e.g., ONNX, llama.cpp) | Server node | Model load takes 10–60s; must be kept in memory |
| WebSocket message handler | Server node | Open socket must persist across multiple message exchanges |
| CDC (Change Data Capture) consumer | Server node | Cursor position and stream reader must persist |
| In-memory embedding cache | Server node | Cache must be shared across concurrent workflow calls |
| Rule evaluation (via IRuleEngineClient) | Standard | Remote rule engine; client is injected, no local state |
| SMTP email send | Standard | SMTP client created per send; connection not reused |
| GPU-accelerated image classification | Server node | GPU context and model weights must stay loaded |
Resource Considerations
Server nodes consume resources (memory, file handles, threads) for the lifetime of the process. Before choosing the server node pattern, confirm:
- The resource consumption is acceptable across all deployed environments (development, staging, production)
- The server node implements graceful
StopAsynccleanup so resources are released on shutdown - The server node exposes health metrics so operations teams can monitor its state
External service as an alternative: If a capability requires large startup resources but is shared across many BizFirstGO components (not just workflow nodes), consider hosting it as an external MCP server or microservice rather than a server node in the workflow process. This keeps the workflow host lean and allows independent scaling.