That is excellent. I've had to tackle a similar issue at my current place, except I am chaining long data pipelines with external repositories together. My solve was an api gateway that was verbose but highly configurable.
I wonder if you've felt the pressure of implementing or embedding a scripting language client side? You're already developing a DSL, whether it's text or graphical is not 100% the point.
> I wonder if you've felt the pressure of implementing or embedding a scripting language client side? You're already developing a DSL, whether it's text or graphical is not 100% the point
So, yes.
Right now, there's a clear division of labor: Python goes in the "developer" half of the app, and is used to make data sources or "steps" that can be used in the VPL.
The visual scripting language only exists in the "account" side of the app.
So far, this division of labor is working, but we have encountered a few times where it would be convenient to just put Python code directly into the account side of the app.
About the part where you said, "whether it's text or graphical is not 100% the point" - I do think a graphical scripting interface is absolutely key, actually. Sometimes I forget how much of a wall an actual programming language is for folks. I've been blown away by how productive our support staff has been in our VPL.
I wonder if you've felt the pressure of implementing or embedding a scripting language client side? You're already developing a DSL, whether it's text or graphical is not 100% the point.