Feature: configuration about riess.js HOT 12 OPEN

Yes!

I also think our config-getter should be super thin layer — maybe just wrapping some lodash _.get() and _.has() methods. And yes, like you say, gotta keep in mind that people might want to extend it to grab parts of configs from database etc.

Sometimes I need to do something like config.get('key', 'defaultValue') but that can be done also by _.defaultTo(config.get('key'), 'defaultValue').

So the actual folder would look like this?

.
├── config
│   ├── config.default.js
│   ├── config.local.js
│   ├── config.local.sample.js
│   └── index.js

Just leaving these here for some food for thought:

• https://www.npmjs.com/package/config
• https://www.npmjs.com/package/config-js

from riess.js.

I think the config package is quite an overkill, especially because it's actually supporting the multi-environment config files and that's something I'm trying to move apart from and simplify the config management.

from riess.js.

@lirantal I'm trying to understand your idea on moving away from environment specific configurations. Can you offer up an example configuration file, and how one would have different settings for dev, test, and a file with very private settings (which is what I use for personal api keys & passwords.)

from riess.js.

hey @mleanos, thanks for chiming in, I'm happy to talk about it and exchange ideas :)

it's a broad topic to discuss and encompass many areas (app configuration mgmt that is), but to give some context, if the code base has instances of things like:

if (config.env === 'dev') {
  // doDevDebug()
}

then it's a code smell that there's a coupling of awareness between the environments your app is deployed and the actual app code. what if tomorrow you need to enable that doDevDebug() on an alpha, or staging environment? why does your code care or knows about which environment it is being deployed?

instead, you can do:

if (config.doDevDebug) {
  // doDevDebug()
}

hopefully this already sounds good.
but now, you ask how does the app get a configuration that is suitable for the environment that it's in? that's where more sophisticated config mgmt systems come in play - they are aware of the environments and they deploy configuration accordingly.

what do you think?

from riess.js.

I agree with most, if not all, of what you just said. I prefer if (config.doDevDebug) as well. From what I read earlier in this thread, I was afraid you meant the former (if (config.env === 'dev')).

This bullet point is what I'm mostly curious about:

Configuration file should be just one, to encapsulate all config items regardless of environments.

I can agree with keeping only one configuration file, if we also have one "local" file that can be used for importing settings that shouldn't be passed around environments/repo's. This is how I use MEAN.js's "local" config feature in some of my deployed environments. I think the motivation behind the "local" env files was based on .NET's "secrets" config file. I would like to see something similar here as well.

from riess.js.

I can agree with keeping only one configuration file, if we also have one "local" file that can be used for importing settings that shouldn't be passed around environments/repo's.

I say that lightly :) If you're proposing a one file configuration (without the "local" file), then I'm sure we can figure out a good solution.

from riess.js.

definitely something to figure out as I haven't yet decided on how to manage this for Riess specifically.

from riess.js.

I'm very interested in getting started on this, and as Liran mentioned there are many different ways for us to handle this. So here are more thoughts that I have on the topic..

• I like the idea of using a .json file instead of .js for the configuration file. When we use the latter, and export the settings as an object, it essentially works the same as the former. However, I don't see why we'd need to add any logic to the configuration file, so why not just use JSON?

• I like the idea of using a service to manage the configuration, and using something like config.get('key', 'defaultValue'). I suppose the inner logic of the config.get() method could "look" for the key existing in a class instance of ApplicationConfiguration (or something similar). I point this out because I prefer using classes to manage the individual settings, so that I can add default logic or extend it in the future, rather than working just an object. Does this sound like the right approach?

from riess.js.

In terms of the config file, what I imagine is that there will be a config init setup that will load configuration from either a json file, or allow to read same JSON key entries from environment variables.

If we throw in a service to read configuration from like etcd, then a configuration file could be completely replaced by such key value store, and you'd only want to get very basic configuration from an environment variable like the API address of etcd and stuff like that which is needed for basic operations of the configuration part.

The config keys/values will not be in the code. The idea is to separate them entirely so you won't be able to "host" them in classes. What kind of logic would you want to add to a config key? why not just do that logic at a specific code level where it's used in the code?

from riess.js.

hello, I will work on this subject on our fork, what do you think about a solution like this :

https://codingsans.com/blog/node-config-best-practices

I saw that the work was stopped in progress, someone wants to end it? or do I do it on my side? @mleanos @simison @mleanos

from riess.js.

Hi all,
I will implement the solution linked by @PierreBrisorgueil on the fork and report you my feedbacks.
@mleanos @simison

from riess.js.

Hi all @mleanos @lirantal @simison , we have done first version of configuration here

Two files, Development (default) & production, everything can be override by ENV VARS. The goal is to no longer need to touch the files, but only to set via variables of env.

Do not hesitate to give us a feedback.

we hosted a first demo Angular + Node : http://meanie.weareopensource.me/home

(and just start a back NEST, If some want to help, we need people to hope someday to cover REACT SWIFT GO NODE NEST ANGULAR ... )

@techla

from riess.js.