[HN Gopher] FlowSynx - Orchestrate Declarative, Plugin-Driven DA...
___________________________________________________________________
FlowSynx - Orchestrate Declarative, Plugin-Driven DAG Workflows on
.NET
Author : flowsynx
Score : 46 points
Date : 2025-10-01 10:00 UTC (13 hours ago)
(HTM) web link (flowsynx.io)
(TXT) w3m dump (flowsynx.io)
| flowsynx wrote:
| 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.
| pragmatic wrote:
| 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?
| orphea wrote:
| 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...
| Atotalnoob wrote:
| Workflow core is more like airflow
| osigurdson wrote:
| >> 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.
| bertylicious wrote:
| 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.
| giancarlostoro wrote:
| > 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.
| osigurdson wrote:
| 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).
| giancarlostoro wrote:
| I'm not saying its bad, I'm just saying nobody is
| consistent in strategy and it frustrates me. Yeah I'm on
| about how .env can just be a file.
|
| https://www.nuget.org/packages/dotenv.net
| DoctorOW wrote:
| Small typo in your docs :)
|
| https://flowsynx.io/docs/overview/ |
| https://i.imgur.com/5trYnvj.png
| orphea wrote:
| 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 :)
| hudo wrote:
| 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...
| debarshri wrote:
| It funny how this is the first problem statement all backend
| engineers think of.
___________________________________________________________________
(page generated 2025-10-01 23:01 UTC)