4 ms·
The idea of a pseudo flow based programming worfklow has always appealed to me because I think having logic as components that can be used as legos makes sense.
by Ataraxy 6y ago
The idea of a pseudo flow based programming worfklow has always appealed to me because I think having logic as components that can be used as legos makes sense. It seemed like the other stuff out there was either too overkill/obtuse or even too low level for what I had in mind. So I started writing something for personal use in JS that fits my mental model of what that would be.
In a nutshell it's just a runner and uses a project called moleculer which is a microservice framework that I'm more or less just using as an rpc client to execute the tasks of the workflow.
One thing I've been debating with myself is how I should work with the dataflow. Would you say it's better to have the results of every node merged into a singular context across an entire flow that is passed to every other node/block (ie. always one input, the context, one output the context), or would it be better to explicitly declare and pass in inputs/outputs.
Here's one project that does it that way: https://github.com/danielduarte/flowed https://github.com/danielduarte/flowed
One benefit of this seems to be that nodes can run in parallel the moment their dependencies are met without having to care about each other.
I poked around on your site and I like what you have to offer. You appear to do it the singular context way which I suppose makes sense because it seems like every block is an individual lambda. This also seems like overkill for my purposes because I'm interested in being able to do granular things if I wish such as a simpe rule action. I'm not sure having an individual lambda to run "if email exists return true" would be practical. That and the warm up time/latency.
The other thing is managing something like npm dependencies might be annoying across blocks.
Being able to create arbitrary API endpoints is nice though.
I wish there were something a little more in between than all of these enterprisey offerings.