🚀 Add support for 3 styles of graphs: Root | Decision | Flow

[chrisjpatty]

This PR is a work in progress to add support for one of Flume's most requested features: decision-style graphs. Right now Flume only natively supports "root-style" graphs, in which inputs for all nodes may only be connected to one output port, and output ports may be connected to any number of input ports. In a decision-tree style graph, you may have any number of inputs or outputs connected to each other, but the resolution of these graphs will have to be different than the first-class RootEngine support. In creating this feature it would be simple to also add support for a 3rd style of graph I'm calling "flow-style" graphs. Flow-style graphs are like root-style graphs in reverse. An input can have any number of outputs connected to it, but each output may only be connected to one input. This would be an uncommon use-case, but support is easy to add as a side-benefit of adding support for decision trees.

So to summarize the different connection modes:

root (default)

• Inputs: max of 1
• Outputs: one to many

decision

• Inputs: one to many
• Outputs: one to many

flow

• Inputs one to many
• Outputs: max of 1

Right now I'm controlling these modes with a prop on the editor called connectionMode which accepts one of the above three values as a string. I'm open to other ideas for an API here though, or different names for the above three modes for that matter.

I'll track the progress for this PR here:

• [x] connectionMode prop
• [x] Add support for connecting multiple outputs to an input
• [x] Add support for deleting a single input connection if multiple are present
• [x] Add a warning to the RootEngine if the nodes passed in do not conform to the root-style
• [ ] Add tests for the new functionality
• [ ] Update documentation with references to new features

Work that will probably happen in a future PR:

• [ ] Add a DecisionEngine for resolving decision trees
• [ ] Add a FlowEngine for resolving flow graphs

Feedback of any kind is more than welcome! Neither of these are features that I personally have a reason to use as of yet so I would love to get feedback from people who have asked for, and plan to use them.

Resolves #66 and #29

[chrisjpatty]

CC: @PhilGarb and @patrickap-bkklinde . Since you've both filed issues asking for this feature I would love to get your feedback before it's merged in.

[chrisjpatty]

An alternative API I've toyed with instead of the three connection "modes", is two separate props: maxInputs, and maxOutputs, and they would default to 1 and -1 respectively (-1 denoting that there is no max outputs). I'm still leaning towards the connectionMode, but I'm not sold on it just yet.

[ghost]

Thank you @chrisjpatty, unfortunately I can't get the pull request to work, so I can't test it. But in terms of considerations, I like the naming of the connection modes and would prefer just one prop connectionMode.

Something else I can think of: Have you considered moving this setting to the node level? Wouldn't that have the advantage of being much more flexible or does it just make things complicated?

[augusto3691]

This PR is a work in progress to add support for one of Flume's most requested features: decision-style graphs. Right now Flume only natively supports "root-style" graphs, in which inputs for all nodes may only be connected to one output port, and output ports may be connected to any number of input ports. In a decision-tree style graph, you may have any number of inputs or outputs connected to each other, but the resolution of these graphs will have to be different than the first-class RootEngine support. In creating this feature it would be simple to also add support for a 3rd style of graph I'm calling "flow-style" graphs. Flow-style graphs are like root-style graphs in reverse. An input can have any number of outputs connected to it, but each output may only be connected to one input. This would be an uncommon use-case, but support is easy to add as a side-benefit of adding support for decision trees.

So to summarize the different connection modes:

root (default)

• Inputs: max of 1
• Outputs: one to many

decision

• Inputs: one to many
• Outputs: one to many

flow

• Inputs one to many
• Outputs: max of 1

Right now I'm controlling these modes with a prop on the editor called connectionMode which accepts one of the above three values as a string. I'm open to other ideas for an API here though, or different names for the above three modes for that matter.

I'll track the progress for this PR here:

• [x] connectionMode prop
• [x] Add support for connecting multiple outputs to an input
• [x] Add support for deleting a single input connection if multiple are present
• [x] Add a warning to the RootEngine if the nodes passed in do not conform to the root-style
• [ ] Add tests for the new functionality
• [ ] Update documentation with references to new features

Work that will probably happen in a future PR:

• [ ] Add a DecisionEngine for resolving decision trees
• [ ] Add a FlowEngine for resolving flow graphs

Feedback of any kind is more than welcome! Neither of these are features that I personally have a reason to use as of yet so I would love to get feedback from people who have asked for, and plan to use them.

Resolves #66 and #29

need that....please...

[augusto3691]

@chrisjpatty im trying to use that branch in my project, even thought is not implemented, im just testing, and can make that work, i need to compile it in order to use it?

[PhilGarb]

Hi @chrisjpatty,

sorry for the late response. I am very happy to see better support for decision-style graphs directly in flume. We have found that it became quite difficult to represent our use case (as described in #29) only with root-style graphs.

An alternative API I've toyed with instead of the three connection "modes", is two separate props: maxInputs, and maxOutputs, and they would default to 1 and -1 respectively (-1 denoting that there is no max outputs). I'm still leaning towards the connectionMode, but I'm not sold on it just yet.

In regards to the API I am wondering how much of the logic of a specific graph model flume should contain. Now that flume starts to support more kinds of graphs and is not focused on a specific use case anymore I wonder whether it would be better for flume to be just the representational logic of showing a graph. All implementations with their specific rules could then be build upon this base layer. In this case I would go with the API that is more flexible. maxInputs and maxOutputs seem to be this API (I think).

Something else I can think of: Have you considered moving this setting to the node level? Wouldn't that have the advantage of being much more flexible or does it just make things complicated?

I would also second the question from @patrickap-bkklinde about having this setting at the node level. What I have found is that the distinction between different kinds of graphs, and their associated rules, is more a result of the type of the root engine and not of the graph itself. The graph itself might contain elements from root (flow) or decision style graphs. In these cases it might be interesting to configure how many connections individual ports accept depending on the Node. I do not know how possible a flexible RootEngine, that could handle these different kinds of Nodes, would be. Do you already have an idea about how you would implement the Decision Tree Engine?

[wlievens]

Just curious, is work on this feature still going on? Would love to use it.

[danlobo]

Hey @chrisjpatty , can I help coding this feature?

[ninjrdevelop]

With the RootGraph being essentially RootNode at the end, calculate from there backwards to find the end-result of the RootNode.

If I'm understanding the Decision Graph properly, it would essentially be the RootGraph in reverse? One entry point that can have logic flow from there along different logical nodes etc to end up causing different effects. In line with, say, the Unreal engine's Blueprints?

If that's the case, would there need to be a logic port type for dictating the flow from the Entry node onwards?