FlowSynx – Orchestrate Declarative, Plugin-Driven DAG Workflows on .NET | Hacker News Reader

FlowSynx – Orchestrate Declarative, Plugin-Driven DAG Workflows on .NET

flowsynx.io

55 pointsflowsynx19 comments

Open articleView on HN

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...

Workflow core is more like airflow

>> 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).

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

By strategy, do you mean, the various hierarchies that people use? If so, I agree that sticking to a flat set of key / value pairs is usually fine. A little resistance to hierarchy is generally a good thing in software.

For the really simple flat case with key / value pairs and no grouping or hierarchies, I would recommend that you still use the .NET configuration to define and read the config sources.

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.

Yes, agree about using the regular .NET configuration. That was my suggestion a few comments up. I can see why people might want to do something different (i.e. .env) but I wouldn't use that in a .NET project despite how ugly it is. It is ugly but works well.

>> 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.

> Actually I think .NET config is pretty good. You define a file, which can be overridden by environment variables

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...

> I don't see a serious consensus and it frustrates me.

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...

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?

Agree. This may seem nice and easy for simple demo scenarios, but things always get more complicated ("I just need an if statement here and a switch statement there") and imo code always wins in the end. Perhaps for truly pure data processing pipeline use cases this makes sense.

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

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.

Reply on news.ycombinator.com