Constrain flows to be DAGs?

[benwhalley]

Should the UI constrain nodes to be within a DAG? At present feedback is permitted in the UI, and generates multiple new inputs/outputs.

If flows were DAGs it would be possible to allow to user to automatically rerun the entire flow on making a change in a parent node.

(This project is great BTW. I found it by searching for front end libraries for graph editing because I wanted to make something very similar).

[ianarawjo]

Thank you! Yes I have wanted a "rerun flow" top-level button but it is not so easy with how the code is structured. Constraining to DAG would require some validation mechanism that walks the node graph. Feel free to code one up! If it was coded, the feature would enable a high-level "Rerun flow" button.

[benwhalley]

I actually have a prototype of something similar to chainforge running in python, and I used networkx to build and traverse a DAG, which makes it all really simple.

I actually wondered how tied you were to having all the API-calling stuff be triggered from the javascript? I wasn't sure on the way you wanted to architect things because you obviously have the python server running, but that doesn't really do much other than serve the html and do some of the custom provider calling — but that would be easy to port to js. Have you got a sense of whether you will move towards a server-side system more generally? For me it would be really helpful to be do it that way for a bunch of reasons:

• Primarily, because it would then be possible to create a chain/flow offer an API to call it with new inputs. This makes the shift from prototyping to production much easier. I currently have a Django app which does this (linked lists of templated queries which we call via an API) but it doesn't have the nice UI to build the flows or prototype/test prompts.

• It would be easier to link it up to "RAG nodes". I currently have embeddings in chromadb and my templated prompts can access these embeddings. I have a little markdown based DSL to query embeddings based on an input parameter and spit those into the prompt in a specific place. With chainforge it would be even nicer because you could have a RAG node which takes inputs from other nodes to query the embeddings, and then output that as a parameter to the next prompt.

• With a server-based system also possible to manage API costs better, have quotas etc for different users. I have lots of colleagues who would benefit either from pre-written flows they could adapt/use, or by using an API with pre-written and tested flows. They wouldn't want to have the system running locally though and don't have their own API key.

Hypothetically, would you be interested in using the python backend to keep track of the graph being built in the UI and where you could offload more of the graph traversal and LLM calling logic to the server?