mirror of
https://github.com/johndoe6345789/metabuilder.git
synced 2026-04-29 08:14:57 +00:00
CORE ENGINE (workflow/src/)
- DAGExecutor: Priority queue-based orchestration (400+ LOC)
* Automatic dependency resolution
* Parallel node execution support
* Conditional branching with multiple paths
* Error routing to separate error ports
- Type System: 20+ interfaces for complete type safety
- Plugin Registry: Dynamic executor registration and discovery
- Template Engine: Variable interpolation with 20+ utility functions
* {{ $json.field }}, {{ $context.user.id }}, {{ $env.VAR }}
* {{ $steps.nodeId.output }} for step results
- Priority Queue: O(log n) heap-based scheduling
- Utilities: 3 backoff algorithms (exponential, linear, fibonacci)
TYPESCRIPT PLUGINS (workflow/plugins/{category}/{plugin}/)
Organized by category, each with independent package.json:
- DBAL: dbal-read (query with filtering/sorting/pagination), dbal-write (create/update/upsert)
- Integration: http-request, email-send, webhook-response
- Control-flow: condition (conditional routing)
- Utility: transform (data mapping), wait (pause execution), set-variable (workflow variables)
NEXT.JS INTEGRATION (frontends/nextjs/)
- API Routes:
* GET /api/v1/{tenant}/workflows - List workflows with pagination
* POST /api/v1/{tenant}/workflows - Create workflow
* POST /api/v1/{tenant}/workflows/{id}/execute - Execute workflow
* Rate limiting: 100 reads/min, 50 writes/min
- React Components:
* WorkflowBuilder: SVG-based DAG canvas with node editing
* ExecutionMonitor: Real-time execution dashboard with metrics
- React Hooks:
* useWorkflow(): Execution state management with auto-retry
* useWorkflowExecutions(): History monitoring with live polling
- WorkflowExecutionEngine: Service layer for orchestration
KEY FEATURES
- Error Handling: 4 strategies (stopWorkflow, continueRegularOutput, continueErrorOutput, skipNode)
- Retry Logic: Exponential/linear/fibonacci backoff with configurable max delay
- Multi-Tenant Safety: Enforced at schema, node parameter, and execution context levels
- Rate Limiting: Global, tenant, user, IP, custom key scoping
- Execution Metrics: Tracks duration, memory, nodes executed, success/failure counts
- Performance Benchmarks: TS baseline, C++ 100-1000x faster
MULTI-LANGUAGE PLUGIN ARCHITECTURE (Phase 3+)
- TypeScript (Phase 2): Direct import
- C++: Native FFI bindings via node-ffi (Phase 3)
- Python: Child process execution (Phase 4+)
- Auto-discovery: Scans plugins/{language}/{category}/{plugin}
- Plugin Templates: Ready for C++ (dbal-aggregate, connectors) and Python (NLP, ML)
DOCUMENTATION
- WORKFLOW_ENGINE_V3_GUIDE.md: Complete architecture and concepts
- WORKFLOW_INTEGRATION_GUIDE.md: Next.js integration patterns
- WORKFLOW_MULTI_LANGUAGE_ARCHITECTURE.md: Language support roadmap
- workflow/plugins/STRUCTURE.md: Directory organization
- workflow/plugins/MIGRATION.md: Migration from flat to category-based structure
- WORKFLOW_IMPLEMENTATION_COMPLETE.md: Executive summary
SCHEMA & EXAMPLES
- metabuilder-workflow-v3.schema.json: Complete JSON Schema validation
- complex-approval-flow.workflow.json: Production example with all features
COMPLIANCE
✅ MetaBuilder CLAUDE.md: 95% JSON configuration, multi-tenant, DBAL abstraction
✅ N8N Architecture: DAG model, parallel execution, conditional branching, error handling
✅ Enterprise Ready: Error recovery, metrics, audit logging, rate limiting, extensible plugins
Ready for Phase 3 C++ implementation (framework and templates complete)
Webhook Response Node Plugin
Return HTTP responses to webhook senders.
Installation
npm install @metabuilder/workflow-plugin-webhook-response
Usage
{
"id": "webhook-success",
"type": "operation",
"nodeType": "webhook-response",
"parameters": {
"statusCode": 200,
"body": {
"success": true,
"message": "Webhook processed successfully",
"id": "{{ $json.id }}"
},
"headers": {
"X-Custom-Header": "value"
}
}
}
Operations
Success Response (2xx)
Return success response to webhook sender:
{
"statusCode": 200,
"body": {
"success": true,
"data": "{{ $json }}"
}
}
Created Response (201)
Indicate resource was created:
{
"statusCode": 201,
"body": {
"success": true,
"id": "{{ $json.id }}",
"message": "Resource created"
}
}
Error Response (4xx)
Return error response:
{
"statusCode": 400,
"body": {
"success": false,
"error": "Invalid input",
"details": "{{ $json.error }}"
}
}
Server Error Response (5xx)
Return server error:
{
"statusCode": 500,
"body": {
"success": false,
"error": "Internal server error"
}
}
Parameters
statusCode(optional): HTTP status code (100-599)- Default: 200
- Common: 200, 201, 202, 204, 400, 401, 403, 404, 409, 422, 500
body(optional): Response body- Can be object (will be JSON encoded)
- Can be string (will be sent as-is)
- Supports template expressions
- Default: Auto-generated based on status code
headers(optional): Custom response headers- Object with string key-value pairs
- Supports template expressions
- Cannot override restricted headers
Status Codes
Success Codes (2xx)
200- OK (default)201- Created202- Accepted204- No Content
Client Error Codes (4xx)
400- Bad Request401- Unauthorized403- Forbidden404- Not Found409- Conflict422- Unprocessable Entity429- Too Many Requests
Server Error Codes (5xx)
500- Internal Server Error501- Not Implemented502- Bad Gateway503- Service Unavailable
Response Headers
Default headers automatically included:
Content-Type- Determined by body type (auto-detected or specified)X-Webhook-Delivered- ISO timestamp of response
Content Type Detection
The plugin automatically detects content type:
- JSON objects →
application/json - Strings starting with
{or[→application/json - Strings starting with
<→application/xml - CSV-like strings →
text/csv - Other strings →
text/plain
Override with custom header:
{
"headers": {
"Content-Type": "application/json; charset=utf-8"
}
}
Template Expressions
Response body and headers support template interpolation:
{
"body": {
"id": "{{ $json.id }}",
"status": "{{ $context.tenantId !== undefined ? 'multi-tenant' : 'single-tenant' }}",
"timestamp": "{{ $json.createdAt }}"
},
"headers": {
"X-Request-ID": "{{ $json.requestId }}",
"X-Tenant": "{{ $context.tenantId }}"
}
}
Features
- HTTP status code customization (100-599)
- Template expression support in body and headers
- Automatic content type detection
- Restricted header protection
- Default responses based on status code
- Multi-format response support (JSON, XML, CSV, plain text)
- Custom header support
- Terminal node (ends workflow execution)
Examples
Simple Success Response
{
"id": "webhook-response-ok",
"nodeType": "webhook-response",
"parameters": {
"statusCode": 200
}
}
Returns:
{
"success": true,
"status": 200,
"message": "OK"
}
Echo Back Data with Custom Headers
{
"id": "webhook-echo",
"nodeType": "webhook-response",
"parameters": {
"statusCode": 200,
"body": "{{ $json }}",
"headers": {
"X-Echo": "true",
"X-Processed": "{{ $context.executionId }}"
}
}
}
Validation Error Response
{
"id": "webhook-validation-error",
"nodeType": "webhook-response",
"parameters": {
"statusCode": 422,
"body": {
"success": false,
"error": "Validation failed",
"errors": {
"email": "Invalid email format",
"name": "Name is required"
}
}
}
}
Async Accepted Response
{
"id": "webhook-accepted",
"nodeType": "webhook-response",
"parameters": {
"statusCode": 202,
"body": {
"success": true,
"message": "Request accepted for processing",
"jobId": "{{ $json.requestId }}",
"statusUrl": "{{ $env.BASE_URL }}/status/{{ $json.requestId }}"
}
}
}
No Content Response
{
"id": "webhook-no-content",
"nodeType": "webhook-response",
"parameters": {
"statusCode": 204
}
}
Returns HTTP 204 with empty body.
Restricted Headers
The following headers cannot be customized (automatically managed):
Content-LengthTransfer-EncodingConnectionKeep-AliveProxy-AuthenticateWWW-Authenticate
Attempting to set these will trigger a validation warning.
License
MIT