4.2 KiB
Implementation Phases
This document maps interfaces to implementation phases to help developers focus on what's needed when.
Phase 1.1: Core Runtime Package (MVP)
Goal: Basic expression evaluation working in CLI/backend
Interfaces Needed:
RuntimeBridge- Main bridge interfaceBridgeConfig(withoutdebugfield)RuntimeHostInterface- Runtime-to-host communicationRuntimeGlobals- Globals injected into runtimeWorkflowDataProxy- Data access helperIExpressionEvaluator- Public APIEvaluatorConfig(without observability)WorkflowData- Input data formatEvaluateOptions(basic)
Implementations Required:
IsolatedVmBridge- For CLI/backendExpressionEvaluator- Main evaluator class- Runtime code (runs inside isolate, bundled via esbuild)
- Lazy loading proxies
- Expression code cache (per-evaluator, caches tournament-transformed code)
Can Skip:
- Observability (use
NoOpProviderstub) - Debug mode
- Specific error types (use generic
Error) - Web Workers
- Task runners
Phase 0.2: Observability Infrastructure (PARALLEL)
Goal: Add metrics, traces, and logs
Interfaces Needed:
ObservabilityProviderMetricsAPITracesAPILogsAPISpan
Implementations Required:
NoOpProvider(zero overhead when disabled)OpenTelemetryProviderPostHogProvider(optional)CompositeProvider(use multiple providers)
Integration:
- Add to
EvaluatorConfig.observability - Emit metrics/traces from evaluator and bridge
- Smart sampling implementation
Phase 1.2: Isolate Pooling
Goal: Handle concurrent evaluations
New Interfaces: None (uses existing RuntimeBridge)
Implementations Required:
IsolatePoolclass- Pool configuration
- Acquire/release mechanism
- Disposal detection and replacement
Phase 1.3: Extension Framework
Goal: 100% test compatibility
New Interfaces: None
Implementation: Extension functions in runtime
Phase 1.4: Error Handling
Goal: Graceful error handling with clear messages
Interfaces Needed:
ExpressionErrorMemoryLimitErrorTimeoutErrorSecurityViolationErrorSyntaxError
Implementation: Error handling in all code paths
Phase 2+: Future Enhancements
Web Worker Support
Interfaces: Already defined (same RuntimeBridge)
Implementations:
WebWorkerBridge- Runtime bundled as ESM
- Note: No lazy loading initially (pre-fetch data)
Chrome DevTools Debugging
Config: BridgeConfig.debug field
Implementation:
- Inspector protocol integration
- Debug mode in IsolatedVmBridge
Task Runner Integration (Architecture TBD)
Task runners already have process-level isolation. Expression evaluation happens inside the task runner (no IPC to worker needed).
Option A: Use IsolatedVmBridge locally within task runner
- Adds another sandbox layer for extra security
- Task runner creates local evaluator instance
- No lazy loading needed (task runner has all data)
Option B: Evaluate directly without extra sandbox
- Reuse task runner's existing process isolation
- Simpler, potentially faster
- May be sufficient given process-level isolation
Decision pending - will be made during Phase 2+ implementation.
Quick Start Guides
For Frontend Developers (Web Worker Integration)
Phase 1: Skip - Web Workers are Phase 2+
Phase 2: Focus on:
RuntimeBridgeinterface - Your bridge must implement thisBridgeConfig- Configuration optionsWorkflowDataProxy- How to structure data- Ignore: Observability interfaces (optional)
Key Difference: Web Workers can't do lazy loading initially, so you'll need to pre-fetch all data before calling execute().
For CLI/Backend Developers
Phase 1.1: Focus on:
IsolatedVmBridgeimplementationExpressionEvaluatorclass- Runtime code (runs inside isolate)
- Code cache implementation
Use: NoOpProvider for observability initially
Phase 0.2: Add real observability providers
For Testing
Integration tests use IsolatedVmBridge directly (see src/__tests__/integration.test.ts).
All interfaces in src/types/ are stable enough to write against before the
bridge implementation lands.