mcandeia/deno-workflows

Durable workflows implemented on Edge.

deno-workflows's Issues

Better thread model for workers

https://github.com/mcandeia/deno-workflows/blob/main/workers/worker.ts#L76

Should we use webworkers? Needs measuring performance.

Add open telemetry with support for complete workflow tracing

The parent span should be persisted and reused across the same execution.

Set postgres connection pool proportionally to the worker count

Support WASM runtime

Implement search database for querying indexed executions and events

https://github.com/mcandeia/deno-workflows/blob/main/backends/search.ts

The database for searching executions and events is different from the transactional database. They differ not only in the data model but also in the required capabilities. The transactional database a.k.a WRITE database does not need to support any indexed search, unlike the search database which should support pagination and other complex queries.

The searchDB should be used on the API for querying events and executions

Add race(...commandList) and all(...commandList) commands

They should work exactly how Promise.all and Promise.race works but for commands.

const payloadOrVoid = yield ctx.race([ctx.sleep(10 *Second), ctx.waitForSignal("sms_response")]

This should be modeled as a single command that contains two commands in it. Similarly, a single event should contain execution of both commands.

Add rate limiter for executions APIs

Add unit tests and github action for formatting and run tests

• Add test badge on readme

[SQL Injection] Do not use string interpolation for mounting queries

https://github.com/mcandeia/deno-workflows/blob/main/backends/postgres/db.ts#L52

Add e2e tests in a separated repository

E2E tests should include

• Prove workflow durability (with intermitent failures)
• Prove workflow atomicity (no event commit if the workflow wasn't executed)
• Performance tests for workers (throughput, how long it takes to process 100 workflows of the same types using N workers?)
• Use timers and measure discrepancy between reality and execution time

Support resume/pause workflows

Allow inline run based on a trust-list configuration

Support inline run for workflows based on a trust-list configuration,

The inline support should be based on the workflow alias which can be either, a well-known alias or a reference to a workflow.

The inline alias should follow the following format: inline:${runtime}:${runtime_based_params}

e.g

For the deno runtime params it should be

inline:deno:${ts_file_url}

for the http it should be

inline:http:${http_func_url}

The modifications that needs to be done is all within the same file: https://github.com/mcandeia/deno-workflows/blob/main/registry/registries.ts#L141

A validation might be necessary based on a trust list of such runtime can be used inline with such parameters.

Support serverless workflow format https://github.com/serverlessworkflow/specification

Use typescript SDK to parse workflows and execute them as a new runtime serverlessworkflow.ts inside runtime folder.

Implement auth based upon request signature

Support autoscaling based on pending workflows

How to create a autoscaling rule on any platform?

• Kubernetes
• Flyio

Add workflow wait for completion API/event