Discussion on: Fauda: configuration made simple

[Nicolas Gryman]

Thanks for the feedback Neeraj!

I think this is perfectly fine to stick with yargs and manage configuration manually when it makes sense.

One of Fauda's objectives is to help tools targeting a broad audience with diverse needs and technical backgrounds.

From my experience writing internal tooling at my company, as the audience grows, so do the use cases. Folks come up with various ways of integrating a tool in their workflow. Depending on their tech stack, personal preferences, and technical constraints, they tend to need more than one configuration source simultaneously.

Fauda helps to support all of these use cases out of the box, without spending too much time figuring out the specifics.

---

I would be interested to understand your use case better:

Say I am writing a command-line tool. If I'm doing this in Javascript, I usually use yargs. Either I would have to duplicate the contents of my Fauda config definition JSON schema [...]

Fauda already maps CLI options based on your JSON schema. For instance, a mode option would be mapped to the --mode CLI option. So, in theory, you shouldn't need yargs to parse these options. Are there other reasons you would need yargs?

Also, the fact that configuration can come from so many different sources -- environment variables, command-line arguments, and configuration files -- would make it really difficult to debug a server application that used Fauda to manage its configuration.

That's a good point. I think this is inherent to having multiple sources of configuration. Possibly Fauda could come up with a solution. I would need to think about it a bit more, but I think a debug mode that displays the currently loaded configuration information could help.

For instance, it could look like something like this:

$ DEBUG=1 MY_APP_MODE=development my-app --port=3000

Option    Value              Sources
--------------------------------------
mode      development        ENV*, FILE
open      false              FILE*
port      3000               CLI*, FILE

The * would indicate the currently used source.

Let me know your thoughts about this and if you think it could help debugging.

[Neeraj Kashyap]

I haven't used yargs in a long time simply because our backend code is written in Python and Go has become my language of choice for one-off CLI tools. From that point of view, take whatever I say with a grain of salt because my language choices mean I am not a Fauda user by default.

That said, I have spent a lot of time in my life giving devops support to development teams that developed entirely in javascript. These are the experiences that made me wary of libraries like dotenv.

Even in javascript, i really dislike yargs - it just so happens that that's the library that I'm (unfortunately) most familiar with. Would be happy to switch to something like Fauda.

Your idea of a debug mode is fantastic. Some suggestions of different flavors:

1. It is valuable to know how a given invocation of my-app is configured, complete with values from the command line. Maybe a command like fauda inspect <my-app invocation taken from output of ps command>?

2. If a config value came from a file, would be nice to know the file path.

3. If a config value came from an environment variable, would be nice to know the env var name.

4. If a config value came from the CLI, maybe a snippet of the invocation with the argument highlighted?

To build sympathy for this use case, imagine you know almost nothing about the application. You are trying to debug some error message from your production logs by shelling into the server/container running that application. Once you are in, you want to know as quickly as possible:

1. how the application was invoked

2. what parameters it is using

If the application is using Fauda and I can use Fauda to get this information easily, I would forever recommend it to all JS developers I know.

[Nicolas Gryman]

Thanks for the feedback!

I like the idea of having a fauda inspect. It could be a non-intrusive way to debug an already running Fauda-configured app.

I believe this could end up in unpredictable results though. The configuration file or the environment variables might have changed since the app has started, and fauda inspect could return values that don't reflect the startup app's configuration.

I think this could work if we enabled some communication between a Fauda-configured app and fauda inspect (e.g. socket). However, this would quickly add complexity to the current implementation. 😅

Do you see any other approaches that could allow fauda inspect to inspect an already running app?

[Neeraj Kashyap]

You know, I need to retract my previous statement about Viper (github.com/spf13/viper). Used it this weekend to build a command line tool in Go, and I found it to be quite useful.

This is the tool: github.com/bugout-dev/bugout-go

When someone installs that tool, they get access to a bugout binary. They can initialize a config file using bugout state init. The approach I've taken to inspecting state is bugout state current. This shows the config file path as well as the current config key-value pairs.

It's nowhere near as comprehensive as what Fauda allows you to do, but it suggests a different approach than a live Fauda socket (which, as you rightly pointed out, is way too much complexity). Instead, you can just write (atomically) Fauda state into a tempfile and read the most recent state from that file on fauda inspect.