[Design Discussion] Flow composer layouts in graph definition

[ThaminduDilshan]

Related Feature Issue

#458

Problem Summary

Currently thunder only supports a pure backend based flow definition where an authentication/ registration flow can be defined in a graph representation in a json file. The flow execution engine takes the graph as the input and traverse through the nodes based on flow inputs.

However this representation is not user friendly and we need to have a step based drag and drop UI composer to define/ edit flows. As a prerequisite, this requires the introduction of a flow management API along with the management service that is discussed in #812.

Composer provides a drag and drop UI experience where it require to store layout information along with flow graph to be consumed when viewing/ modifying a defined flow graphs. Ideally composer components should be rendered in the same places where the user left them off previously.

Proposed Approach

<Suggesting on top of the solution proposed in #812>

Each node in the graph must have a property/ config to represent it's composer layout. This needs to capture both positioning (x, y coordinates) and size (width, height) of the node box in the composer. The suggestion is to define a layout block for positioning information as follows.

{
    "id": "my_node",
    "type": "TASK_EXECUTION",
    "layout": {
        "size": {
            "width": 200,
            "height": 150
        },
        "position": {
            "x": 100,
            "y": 100
        }
    },
    ...

• size: width and height of the node box in flow composer UI
• position: x, y coordinates of the node box in the flow composer canvas

Technical Questions for Discussion

1. Every node needs to have the layout information for the flow composer UI. The proposed approach uses a first level layout element. Alternatively this can be added to the existing node properties; however current idea of properties is to be used for the backend execution. This will mixup backend properties with the frontend composer layouts. Is there any concern with the proposed model?

Alternative Approaches

N/A

Architecture and Components

No response

Security Considerations

N/A

Implementation Complexity

Low (1-2 weeks)

Areas of Thunder that will be impacted

• Authentication
• Registration

Questions for Community Input

No response

[ThaminduDilshan]

Proceeded with the suggestion