10. Complex Plugin Interactions

  • Status: [accepted]

  • Deciders: [Fabian Bühler]

  • Date: [2021-09-03]

10.1. Context and Problem Statement

Plugins can already create and modify data. However, a plugin can only directly expose one processing resource to the QHAna UI. This limits the possible interactions with a plugin. Plugins cannot cooperate with other plugins or ask for user input in a multi step process.

10.2. Decision Drivers

  • We want to enable plugin cooperation (e.g. an optimizer plugin optimizing any optimizable quantum circuit)

  • We want to enable multi step processes where the user may be required to input data at every step

10.3. Considered Options

  • Implement Workflows or integrate a Workflow Tool (like Camunda) + Engine

  • Hardcoded multi-plugin templates

  • Multi step micro frontends

10.4. Decision Outcome

Chosen option: “Multi step micro frontends”, because it is easy to implement and allows very complex interaction patterns with plugins.

10.4.1. Positive Consequences

  • Complex plugin interactions will be possible

  • Complex interactions must not be hardcoded (like in option “Hardcoded multi-plugin templates”)

  • Allows creation of meta plugins that compose multiple plugins into one functionality

  • Easy to implement

10.4.2. Negative Consequences

  • Meta plugins are not real workflows

  • Creating more and more complex micro frontends is neccessary to take advantage of this feature

10.5. Pros and Cons of the Options

10.5.1. Implement Workflows or integrate a Workflow Tool (like Camunda) + Engine

Implement full workflow support in QHAna

  • Good, because it would allow basically any interaction pattern with plugins

  • Good, because workflows are powerful

  • Bad, because workflows are not easy to create learn (steep learning curve, technical/deployment details need experts)

  • Bad, because workflows are typically not executed one activity at a time (while in QHAna executing one Plugin at a time is the norm)

  • Bad, because integrating workflows is a huge task and thus hard to implement

10.5.2. Hardcoded multi-plugin templates

For typical multi plugin use cases one could implement hardcoded workflow like multi-plugin templates that specify how and in which order to invoke plugins. The user would select the plugins for the template in a first step and then be guided through the whole process. Plugins provide metadata (e.g. tags describing what type of plugin they are) that can be used for this.

  • Good, because allows for some complex interaction patterns involving multiple plugins

  • Good, because relatively easy to implement

  • Bad, because the approach is not flexible

  • Bad, because the approach needs to be implemented in the QHAna UI

10.5.3. Multi step micro frontends

Instead of directly producing data a plugin could return a link to a new micro frontend. This new micro frontend would then be presented to the user who could input the required data. This can be repeated until a final result can be presented by the plugin.

  • Good, because it allows for many complex interaction patterns with one or multiple plugins

  • Good, because it is easy to implement in the frontend

  • Bad, because it is harder to implement for plugins (but should not be neccessary for most plugins)