Improve configuration process

[relu91]

Currently, Zion utilizes a simple Env base configuration workflow. We should organize configuration parameters in a hierarchical data structure. Moreover, we have to keep in mind different developer workflows and experiences. This means that we need the flexibility to configure Zion from different sources with different priorities (like JSON/YAML files, CLI parameters, ENVs). This issue serves also as a place to evaluate different ideas before going to the PR phase.

Todos:

• Refactoring code to have a structured config model
• Support different development environments
• Hooks on package.json
• Configuration file support
• CLI support
• Review and check the defaults

Sources:

1. Nest configuration
2. Commander in Nest

[relu91]

To summarize today's call:

• Refactoring code to have a structured config model
• Support different development environments (prod, dev, staging)
• Hooks on package.json
• Configuration file support (maybe)
• Review and check the defaults
• CLI support (next up)

[relu91]

Configuration file support (maybe)

Some feedback from today's call. We discussed the possibility of implementing support for a configuration file and CLI argument but we didn't find a concrete agreement.

But we've found these truths:

• Is that is not that standard to use only envs as configuration
• There's no standard priority schema in regards to envs and config files
• It seems that CLI args always has a priority
• Config files have the advantage of providing structure to configs
• We agree that config files can be used to create different software structures (or flavors). They can be useful to pre-ship a docker already configured for a particular use case.

@hyperloris clear view: we should have three ways to configure the system (envs, config, CLI) BUT there should be a precise mapping between the three. The priority should be CLI > ENVs > File. He doesn't know the structure of the config file. Here is an example:

• https://www.postgresql.org/docs/9.3/config-setting.html

[relu91]

So we decided the final task list that can be find in the issue description

[relu91]

@ivanzy still thinks that right now File support is overkill and should be deferred.

[relu91]

@hyperloris clear view: we should have three ways to configure the system (envs, config, CLI) BUT there should be a precise mapping between the three. The priority should be CLI > ENVs > File. He doesn't know the structure of the config file.

After #28, @ivanzy may I ask you to implement the logic above?

[ivanzy]

Okay, I will start to work on that. Just to clarify:

• CLI means to set ENV when executing the command, e.g.,NODE_ENV=production node dist/src/main; or it is through custom designed flags?
• ENVs are clear
• File is a custom configuration file in YAML. Is there the need or motivation to use another structure?

[relu91]

CLI means to set ENV when executing the command, e.g.,NODE_ENV=production node dist/src/main; or it is through custom designed flags?

custom flags, to follow what @hyperloris said:

BUT there should be a precise mapping between the three

I think if an ENV is ZION_PERSISTENCE_DB_PORT then the corresponding CLI parameter is --persistence.db.port.

File is a custom configuration file in YAML. Is there the need or motivation to use another structure?

If there is already some support for YAML, I won't complain. But I also like JSON + JSONSchema as a file configuration ( I little bit overkill but it depends on how much zion will grow).

[relu91]

ZION_PERSISTENCE_DB_PORT

By the way, I've just noticed all the ENVs should be prefixed with ZION. It is a good practice to avoid conflicts with other services in non-docker environments.