Loopback-next: [Spike] Allow extensions to contribute custom convention for environment-specific operational configuration

[bajtos]

Timeboxed to 2 weeks; don't spend extra time if done earlier

Different platforms use different ways for configuring operational aspects of application in test/dev/production. LB4 should make it easy to write extensions to support these different platforms.

The goal of this spike is to find out and document what's possible today, identify gaps, propose solutions and create a list of follow-up tasks.

Few examples of operational config:

• configure datasources from environment variables
• use a faster but less-secure hashing algorithm in dev/test (a hashing algorithm is used e.g. to store user passwords)
• apply datasource configuration provided by VCAP_SERVICES env variable in CloudFoundry/IBM Cloud - see https://github.com/strongloop/loopback-next/pull/1574

Possibly related: https://github.com/strongloop/loopback-next/pull/983 and https://github.com/strongloop/loopback-next/issues/1396

[Edo78]

Is there any news about this issue?
Right now the only way I have found to configure a datasource with environment variables is to instantiate the related class (in application.ts) passing a custom configuration

let dbDataSource = new DbDataSource({
  name: 'db',    
  connector: 'mysql',
  hostname: process.env.DB_HOST,
  port: process.env.DB_PORT,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_DATABASE
});

but I'm not sure this could be a best practice.
Am I missing something?

[bajtos]

@Edo78 see the following resources to learn about other options available:

• https://loopback.io/doc/en/lb4/Deploying-to-IBM-Cloud.html#updating-application
• https://itnext.io/loopback-4-database-configuration-8f085399268

TL;DR: if you are using @loopback/boot to load your datasources (as is the default in LB4 applications scaffolded using lb4 CLI tool), then you can bind just the custom datasource configuration.

this.bind('datasources.config.db').to({
  name: 'db',    
  connector: 'mysql',
  hostname: process.env.DB_HOST,
  port: process.env.DB_PORT,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_DATABASE
});

[bajtos]

Cross-posting from https://github.com/strongloop/loopback-next/issues/1609

https://github.com/strongloop/loopback-next/issues/441#issuecomment-392522724 #4

In your proposal, the configuration (loaded from JSON) is hard-coded in the generated (base) class. At the same time, we need to support different configurations for different environments (dev/test/production) and load configuration from environment variables (https://12factor.net).

It was proposed to parse process.env variables inside datasource files. I consider that as an anti-pattern, because it couples high-level datasources with low/system-level configuration code. It makes the code difficult to test, because tests would have to manipulate global process.env. Instead, we should find a way how to inject ENV variables in such way that the actual usage of process.env stays in the top-level index.ts or application.ts file only.

On a similar topic, @raymondfeng proposed a sort of a registry holding datasource configuration for all environments in the app-level Context. I don't think this is a good solution - consider the case where an application is deployed to different geo location and where each geo location requires different connection strings (to use a colocated database instance). In other words, a production config is not a single object, but a set of location-specific objects.

My conclusion is that we should decouple datasource configuration from datasource implementation class and leverage dependency injection to provide arbitrary runtime-specific configuration from the application level. IMO, this addressed both needs 1) have different datasource config depending on dev/test/prod environment 2) build datasource configuration dynamically, either from process.env or perhaps external config providers like https://www.consul.io.

A mock-up app:

    class MyApp extends RestApplication {
      async boot() {
        const dbConfig = 
          // Figure out what config to use.  @loopback/boot can provide
          // helpers to load config from ENV variables
        this.bind('datasources.db$config').to(dbConfig);
        // etc.
      }
    }

A mock-up datasource:

    // default config is used in tests
    const defaultConfig = require('./db.datasource.json');

    class DbDataSource extends juggler.DataSource {
      constructor(
        @inject('datasources.db$config')
        config: DataSourceOptions = defaultConfig
      ) {
        super(config);
      }
    }

[adesege]

I was going to create a new issue before seeing this one.

In order not to pollute the codebase with process.env and also to have a central place to manage environment/config variables, we can have a config.json file for example and use dependency injection or decorators to load it for use in a class.

// sample decorator signature
class SampleClass {
 @env('privateid')
 privateId: string;

@env('appSecret')
 appSecret: string;

constructor() {}
}

This can be in a separate package too under @loopback/env.

I am currently working on something similar and I will be glad to raise my first PR if approved.

Let me know what you think 💪

cc: @bajtos

[stale[bot]]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[stale[bot]]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.