FlowSynx – Orchestrate Declarative, Plugin-Driven DAG Workflows on .NET
flowsynx.io43 points by flowsynx 8 hours ago
43 points by flowsynx 8 hours ago
Oh, I thought it would be like Airflow but for .NET.
Absolutely not a fan of secrets in plain text: https://github.com/flowsynx/samples/blob/master/workflows/ni...
>> Absolutely not a fan of secrets in plain text:
If this is standard .NET config, this can be overridden by an environment variable. So, not an issue in production.
This doesn't look like a standard .net config (appsettings.json) to me. It looks more like a simple json serialization of an object. To get the framework behavior that replaces secrets with e.g. env vars one would have to feed this json into a .net ConfigurationBuilder first.
Considering that this represents one of many possible workflow objects (probably organized in a data structure and managed by other objects/methods), implementing secret replacement using a ConfigurationBuilder seems like abuse.
> This doesn't look like a standard .net config (appsettings.json) to me.
Having done... enough .NET I don't see a serious consensus and it frustrates me. My favorite was the project that used dot ENV files. I have tried to convince them of it here, but nobody cares enough about the craft I suppose, of course there's more important things to be worked on, momentary change for increased dev experience is not worth it the business.
Actually I think .NET config is pretty good. You define a file, which can be overridden by environment variables which in turn can be overridden by command line parameters. Just reading environment variables is fine as well but then you have to do source .env before you run anything (unless you are talking about Python like approach where .env is just another config file essentially).
We’re excited to introduce FlowSynx, a powerful new workflow orchestration engine designed to seamless Workflow Automation—Declarative, Extensible, and Fully Controllable. Turn complex processes into maintainable, auditable, and transparent workflows that adapt to your business needs.
Why FlowSynx? Most orchestration tools lock you into rigid ecosystems. FlowSynx takes a plugin-first approach, letting you compose Directed Acyclic Graph (DAG) workflows that adapt to your exact needs.
Can I ask why define these in json?
Devs aren't going to like that over c# and data engineers/biz folks want more of a graphical tool.
Who is your audience for this?
Opened samples - bunch of Json config files. Closed Samples. Do they really expect devs to write Json to configure worksflows and tasks!? Even Workflow Foundation had more c# I think...
Small typo in your docs :)
https://flowsynx.io/docs/overview/ | https://i.imgur.com/5trYnvj.png
Also "Intraction tools" on the same page.
I guess it means a fellow human being was working on the docs, not an AI, which is always great to see :)
It funny how this is the first problem statement all backend engineers think of.
