3 ms·

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/n

• Atotalnoob 1y ago
  Workflow core is more like airflow
• osigurdson 1y ago
  >> 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 1y ago
    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 1y ago
      > 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 1y ago
        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 1y ago
          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 https://www.nuget.org/packages/dotenv.net
          • osigurdson 1y ago
            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.
            • SideburnsOfDoom 1y ago
              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.