Flowsynx – Orchestrate Declarative, Plugin-Driven Dag Workflows on .net
Posted3 months agoActive3 months ago
flowsynx.ioTechstory
skepticalmixed
Debate
60/100
Workflow Orchestration.netWorkflow Automation
Key topics
Workflow Orchestration
.net
Workflow Automation
FlowSynx, a new .NET workflow orchestration engine, is introduced, sparking discussion around its declarative and plugin-driven approach, with some users expressing skepticism about its configuration and security.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
N/A
Peak period
10
0-6h
Avg / period
2.7
Comment distribution19 data points
Loading chart...
Based on 19 loaded comments
Key moments
- 01Story posted
Oct 1, 2025 at 6:00 AM EDT
3 months ago
Step 01 - 02First comment
Oct 1, 2025 at 6:00 AM EDT
0s after posting
Step 02 - 03Peak activity
10 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 5, 2025 at 1:54 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45436027Type: storyLast synced: 11/20/2025, 1:32:57 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.
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?
But code-first approaches to this problem, like that of Temporal [0] (no affiliation), are much nicer in the long run imo.
[0] https://temporal.io/blog/introducing-temporal-dotnet
Absolutely not a fan of secrets in plain text: https://github.com/flowsynx/samples/blob/master/workflows/ni...
If this is standard .NET config, this can be overridden by an environment variable. So, not an issue in production.
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.
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.
https://www.nuget.org/packages/dotenv.net
Then when you need to read a value, inject IConfiguration and call config.GetValue<string>("someKey") or config.GetValue<int>("otherKey") etc. to get values from it in a flat manner.
If you do that enough, you might extract common code or but some other class over it for related settings. At which point you might as well declare a DTO and use IOptions<T>
However what OP has is a whole 80 line workflow definition. I don't recommend storing that kind of thing in the .NET config system at all.
Then if such a large file has sensitive values such as passwords, it will need some find/replace templating system to substitute them from config. e.g. handlebars with "{{somePassword}}" in the file.
>> If you do that enough, you might extract common code or but some other class over it for related settings. At which point you might as well declare a DTO and use IOptions<T>
I think it rarely needs to be that complicated. I overengineered the configuration system for something before and regretted it. People understand GetValue<T>(key) anything else makes them have to think for no reason.
Agreed that it's good. Partly because it's even more flexible than that. There are good defaults, but you decide which sources in which order are use. e.g. in our case it is
appsettings.json
appsettings.{env}.json (e.g. appsettings.dev.json )
Environment variables
There are also providers for places where secrets are stored, such as Azure Key vault (1), which would be layered on last. And a test provider where you just supply some key-value pairs from code (2). Or roll your own (3).
1) https://learn.microsoft.com/en-us/aspnet/core/security/key-v...
2) https://learn.microsoft.com/en-us/dotnet/core/extensions/con...
3) https://vinayakabhat.medium.com/integrating-aws-secrets-mana...
If you're saying that there's no one right way to do it, then I broadly disagree. There's the (very flexible) .NET Configuration system (1) - that is the right way to do it. You should start with appsettings.json and other sources, and end up with injecting IOptions<T> into your code. Consistently.
If you're saying that in your experience, far too many people don't use this system, then who am I to disagree with your experience? Sure, it happens. YMMV. I would be insisting that they move to the .NET Configuration system, though. If they're serious.
1) https://learn.microsoft.com/en-us/dotnet/core/extensions/con...
https://flowsynx.io/docs/overview/ | https://i.imgur.com/5trYnvj.png
I guess it means a fellow human being was working on the docs, not an AI, which is always great to see :)