15. Subscribing for plugin updates

Status: [accepted]
Deciders: [Fabian Bühler]
Date: [2024-02-16]

15.1. Context and Problem Statement

A plugin that invokes another plugin may encounter a situation where the invoked plugin unexpectedly asks for new user inputs in a step. The invoking plugin needs a way to pass this step to the user while still being able to monitor the plugin result for changes.

15.2. Decision Drivers 

Checking for result updates requires expensive polling.
A normal plugin can suspend all execution until the user input is available saving resources
Steps asking for new user input cannot be entirely predicted

15.3. Considered Options

Proxy the micro frontend
Proxy the REST endpoint
Proxy both
Provide a subscription mechanism for update events of the plugin result (accepted)

15.4. Decision Outcome

Implement a subscription mechanism for receiving task result updates via webhook notifications.

15.5. Pros and Cons of the Options

15.5.1. Proxy the micro frontend

Create a proxy frontend that displays the actual frontend for user input but listens to all messages between the proxied micro frontend and the application. The proxy frontend can then notify the plugin when the user input was sent to the invoked plugin. The invoking plugin would copy the step from the invoked plugin and replace the micro frontend url with the proxy frontend url.

Good, because requires only a simple proxy micro frontend and a notification endpoint in the plugin
Bad, because requires nesting iframes (only one level so this would be acceptable)
Bad, because there is no way to detect direct calls to the REST endpoint

15.5.2. Proxy the REST endpoint

Create a proxy endpoint that forwards the user input to the actual REST endpoint while notifying the plugin of the new input. The invoking plugin would copy the step from the invoked plugin and replace the endpoint url with the proxy url.

Good, because the proxy has complete access to the data being sent to the invoked plugin
Good, because this catches direct api calls (to the proxy)
Bad, because the micro frontend is most likely not aware of the new endpoint URL (the endpoint URL is often directly included in the micro frontend code)

15.5.3. Proxy both

This is a combination of the first two proposals. Both the micro frontend and the REST endpoint are proxied.

Good, because (see first two options)
Bad, because it requires more effort to implement two proxies

15.5.4. Provide a subscription mechanism for update events of the plugin result

Require plugins (or the plugin runner) to implement a subscription mechanism that allows servers to subscribe to updates of plugin results. The notification happens via webhook (e.g., by a post request to a specific url).

Good, because this removes the need for polling entirely (for servers with webhooks)
Bad, because it requires more effort to implement (only once in the plugin runner)
Bad, because the subscription process inctroduces more complex behaviour

15.5.4.1. Subscribing to Events

A task result with a link of the type subscribe allows for registering webhooks to receive update events of that task. Once a webhook subscribed to a specifc or all update events it will receive a post call with the url of the task result that is the source of the event and the event type.