Investigate node-config

[feathersjs-ecosystem]

Investigate node-config

[ekryski]

I had been thinking about that as well, or https://github.com/motdotla/dotenv.

[jperl]

@marshallswain I removed my downvote. I think it comes down to whether configuration is a big enough problem that cannot be solved with the existing package ecosystem, and is more important than other problems feathers can work on.

IMO I think it would be best to allow feathers to be configured with a simple options object feathers(options) or feathersApp.initialize(options) and let developers use the existing node packages out there to choose their own flavor of options (dotenv, vault, etc).

[kc-dot-io]

This has been started in #27

[ekryski]

Agreed that dotenv is nice. I use it pretty regularly. However, I think we are going to deprecate this repo and use node-config going forward so we won't be adding that here. I believe node-config already support .env files (and everything else this repo does).

We're just coming up with a migration plan/deprecation strategy which requires updating the generator.

[marshallswain]

It would be nice if we could just use an actual Feathers service for config management. In the not too distant future I see it becoming more common to load config from an actual database. I think it would make a Feathers UI easier to manage. Using a service would make it possible to use any adapter. We could even make a Feathers-json adapter for those who want to keep the config where it is. The config service would be the only thing that really needed a config (sort of ironic:)

[ekryski]

@jperl fair points. Appreciate that. I like that approach. So maybe we should have a feathers.set method that can be used like so.

app.set(options) if you want to pass an object and app.set('key', value) if you want set a specific key name (which would support deeply nested properties by app.set('foo.bar.baz', value)).

I'm thinking app.set('config', configOptions) might be the recommended way and then the generator uses node-config or vault by default but you could use whatever you want to read your options into the app.

We want to be able to expose your config through a service for an internal project so doing app.get('config') inside the service would be super handy. I think this would also allow us to add plugins easily later that maybe make configuration management even more secure/simple (thinking about key rotation and secure storage with vault).

To summarize, possibly the new API is:

• app.set(object)
• app.set('key', value or object)
• app.set('deep.nested.key', value or object)
• app.get('key')
• app.get('deep.nested.key')

[UPDATE] In reality this it not a whole lot different than an in memory service. However, since these get and set methods very likely don't need to deal with async, it makes for a nicer api to not have promises. Although you would be sacrificing the ability to use hooks. Not sure if that is an actual issue.

Thoughts @feathersjs/core-team?

[aboutlo]

node-config allows overriding the settings with runtime variable. dotenv seems useful only in dev mode.

[aboutlo]

I tried to replace this module with node-config in my app.js

// const configuration = require('feathers-configuration');
const configuration = require('config');

then

Object.keys(configuration).forEach(function (name) {
  var value = configuration[name];

  console.log('Setting `' + name + '` to', value);

  app.set(name, value);

  console.log('getting `' + name + '`', app.get(name));
});

everything works like a charm.

I just added custom-environment-variables.json to declare my env variables.

In my opinion, this module could be removed and who needs a config just access the configuration:

e.g. anyfile.js

const config = require('config');
console.log('postgres:', config.get('postgres'));

so that we don't need to pass app just to get the configuration.

cheers Lorenzo

[daffl]

Thanks @aboutlo it's great to know that it works the same. Definitely looks like we can either deprecate feathers-configuration or use node-config under the hood. One thing I would like to find out is how to best deal with asynchronous configuration options though.

[aboutlo]

Using node-config under the hood force to pass a reference to app everywhere. If I understand what you mean. About async it shouldn't change, the configs are loaded when the module is required.

[eddyystop]

@ekryski, https://github.com/motdotla/dotenv is a useful util for sysops which keeps them from mucking with configs in the src. Feathersjs just needs to include a require('dotenv').config({ silent: true });.

[jperl]

+1 for using dotenv. We built this tool to emulate it https://github.com/zipdrug/feathers-configuration-env -- but it would be much nicer to just use dotenv directly.

[jperl]

This package could depend on dotenv and validate / throw errors if any necessary configs are not set.

[kc-dot-io]

I haven't seen it mentioned here that feathers config should support secure storage mechanisms like vault (hashi corp) for secrets. In my experience this is very very important and not typically supported by run of the mill config modules. Its similar to @marshallswain's comment about db storage but vault acts as a proxy that encrypts sensitive information like passwords in said storage and provides a mechanism to do things like seal, unseal or rotate these credentials.

That said. I think we should hand roll this instead of just use the laymen approach as it results with people leaking their keys via public repos or gists.

[marshallswain]

@slajax, Vault looks pretty nifty.
@jperl what are some of the downsides you see to using a feathers service for config management?

[ekryski]

I don't have a ton of experience with vault but from what I've seen it is dope. We've been kicking around the idea of turning this into more of a service, so I've created a separate issue to discuss that option. #24

[kulakowka]

@ekryski it's looks like app.set in expressjs. It`s familiar to most developers. I think it is a good idea.

[daffl]

@slajax Doesn't #27 close this issue?

[kc-dot-io]

Yes. closed by #27