Describe the feature request
Run jobs async via bull queue (like automations).
Instead of having a visual diagram, just have a JavaScript block which allows you to write some code.
There should be binding inputs (like any other query).
Additionally there should be a screen showing active jobs with filter on status:
- Error
- Queued ?
- Running (with percentage - more below)
- Complete
Existing queries should be selectable as functions with their bindings exposed as inputs. E.g.
// There is a SQL query called "Search Rows"
// It has bindings `text` and `limit`
search_rows({ text: "hello", limit: 5 })
Library usage should be heavily restricted, requiring existing queries instead of native fetch for example.
Additionally, there should be a way to emit progress via a helper function.
In code you can manually add progress markers between 0 and 1.
That way when helper.emitProgress(x) is called you will be able to see the percentage progress of the job in a list of jobs.
Describe the feature request
Run jobs async via bull queue (like automations).
Instead of having a visual diagram, just have a JavaScript block which allows you to write some code.
There should be binding inputs (like any other query).
Additionally there should be a screen showing active jobs with filter on status:
Existing queries should be selectable as functions with their bindings exposed as inputs. E.g.
Library usage should be heavily restricted, requiring existing queries instead of native fetch for example.
Additionally, there should be a way to emit progress via a helper function.
In code you can manually add progress markers between 0 and 1.
That way when
helper.emitProgress(x)is called you will be able to see the percentage progress of the job in a list of jobs.