Implement push-based Workflow and Execution updates to Studio via websocket

[chrisli30]

Previously we made a decision to use polling to retrieve workflows and executions, but there are many drawbacks for implementing workflow/execution updates on the client side.

My rationale

When a workflow is triggered, AVS handles a single execution at a time. After the trigger finishes, the resulting event or data is appended to a queue. However, the Studio currently retrieves the entire queue during polling and recalculates it to identify the single item that has changed.

This process could be significantly simplified if we push the single event directly to the Studio.

Advantages of Push-based updates

1. Simplified process:
   • The Studio backend can host a single WebSocket connection to AVS, subscribing to different channels as needed.
   • A secret key can be used to secure the connection and project different channels.
2. Event-specific channels, which could include
   • Workflow events: Creation, cancellation, deletion, or status changes (e.g., “Completed”).
   • Execution events: Start of an execution, success, or error outcomes.

Drawbacks of polling on the client side of Studio

1. Finding a single object or status change from an array is error0prone. If any attribute of workflow or execution change, the code would need to update. It’d be much better if we can push the single event from AVS to user directly.
2. The tranverse of array is costly on cilent side. If not handled carefully, it will cause re-render of some or all page components slowing down the workflow page, especially if polling occurs every few seconds.
3. Although polling works in the beginnning, the number of API calls will add up quickly with a short interval for every user.

Overall, the User Notification feature of the Studio depends on this AVS feature.

[v9n]

The Studio backend can host a single WebSocket connection to AVS, subscribing to different channels as needed.

This functionality is built-in in GRPC. A nodejs process can subscribe and receive real time notification when thing happen. Lets define what information you want to broadcast.

We can define it inside the avs.proto. If a method call ias annote with stream, it will be a subscription. https://grpc.io/docs/languages/node/basics/

Question

1. Does this backend need to update its internal state based on the subscription data? If so, hwo does it handle deployment/downtime and missing event? Will it backfill?

A secret key can be used to secure the connection and project different channels.

Is this new to be a newkey? Can we also use JWT here? Similar to how we generate the API key from CLI currently. We can derive a new key with api

Event-specific channels, which could include

Workflow events: Creation, cancellation, deletion, or status changes (e.g., “Completed”).

Do we need the full workflow data, or just workflow id and status is enough?

Execution events: Start of an execution, success, or error outcomes.

Do we need the full execution even payload in each phase?

[chrisli30]

Novu Endpoint for AVS to send data

Novu Cloud hostname: https://api.novu.co/v1
API Docs: https://docs.novu.co/api-reference/overview