Preferences

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.

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

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

Workflow core is more like airflow

This item has no comments currently.

Keyboard Shortcuts

Story Lists

j
Next story
k
Previous story
Shift+j
Last story
Shift+k
First story
o Enter
Go to story URL
c
Go to comments
u
Go to author

Navigation

Shift+t
Go to top stories
Shift+n
Go to new stories
Shift+b
Go to best stories
Shift+a
Go to Ask HN
Shift+s
Go to Show HN

Miscellaneous

?
Show this modal