EdgeInteract vs. EdgeStream
Both EdgeStream and EdgeInteract deliver real-time messages to the browser — but they serve fundamentally different purposes. Choosing the right one is critical for correctness and system design.
Side-by-Side Comparison
EdgeStream
- One-way: server pushes, client receives
- No response expected from client
- Stateless per message — fire and forget
- Multiple subscribers per topic
- No timeout semantics
- Designed for event streams, dashboards, log feeds
- Client does not need to act on the message
EdgeInteract
- Two-way: server requests, user responds
- Response required (or timeout fires)
- Stateful — tracks pending/responded state
- One responder per interaction (first-to-respond wins)
- Configurable timeout per interaction
- Designed for HIL, approvals, confirmations
- Client must take an action to complete the cycle
Feature Comparison Table
| Feature | EdgeStream | EdgeInteract |
|---|---|---|
| Direction | Server → Client (one-way) | Server ↔ Client (two-way) |
| Response required | No | Yes (or timeout) |
| Message state | Stateless | Stateful (pending → responded) |
| Timeout | None | Per-interaction timeoutMs |
| UI rendering | Your responsibility | Built-in typed components |
| Multi-subscriber | Yes — all subscribers receive | First-to-respond wins (for roles) |
| Awaitable on server | No | Yes — Promise/Task resolves on response |
| Audit trail | Optional | Built-in (request + response logged) |
| Transport | SignalR / WebSocket | EdgeStream (SignalR / WebSocket) |
| Hooks | Message hooks | Pre-send, post-receive, validation, audit |
Decision Guide — Which One to Use?
Use this decision tree to determine which system to reach for:
Does the server need a response from the user?
Yes → Use EdgeInteract. The server will block (asynchronously) until the user responds.
No → Use EdgeStream. Push the message and continue.
Does the workflow or process need to pause and wait?
Yes → Use EdgeInteract. The server awaits the InteractionResponse before continuing.
No → Use EdgeStream. The workflow continues regardless of client state.
Is the message a notification only (no action required)?
It's a notification but you need acknowledgement → Use EdgeInteract's notification type.
It's truly read-only with no action needed → Use EdgeStream.
Are you streaming real-time data (logs, metrics, activity feed)?
Always use EdgeStream. EdgeInteract is not designed for high-frequency event streams.
Use EdgeStream For
- Live execution logs in Flow Studio
- Real-time node status updates in the Observer Panel
- Agent activity feeds in Octopus
- Dashboard metric streams
- Live error feeds
- Broadcast announcements (no response needed)
- Typing indicators, presence updates
Use EdgeInteract For
- Workflow approval gates (HIL nodes in Flow Studio)
- Manager approval requests in WorkDesk inbox
- Collecting user input mid-workflow (form interactions)
- Confirmation dialogs driven by workflow logic
- Octopus agent requesting human authorization
- Multi-party approval (role-targeted, first-to-respond)
- Collecting a choice from a dynamic list (picker)
Architecture Layers
EdgeInteract sits above EdgeStream in the architecture — they are not alternatives at the same layer:
┌─────────────────────────────────────────────┐
│ EdgeInteract │
│ (request/response, typed UI, state, audit) │
├─────────────────────────────────────────────┤
│ EdgeStream │
│ (pub/sub, topics, subscriptions, fan-out) │
├─────────────────────────────────────────────┤
│ Transport: SignalR / WebSocket │
└─────────────────────────────────────────────┘
Your application code uses EdgeInteract for interactions and EdgeStream directly for event streams. Both coexist in the same WebSocket connection.