Decouple wiring of implementation bits from application configuration

[bajtos]

Right now, Application constructor accepts a config/options object that mixes two very different concerns:

1. The functionality/features the application should implement - what controllers it contains, what repositories are registered, etc. ("the assembly instructions")
2. The configuration - what port to listen on, what database servers to connect to, etc.

IMO, the consumers of an application must not change its functionality and features (with the exception of enabling/disabling explicit feature flags) and therefore the config/options argument should contain only the configuration (port numbers, connection strings, feature flags).

Acceptance criteria

• The ApplicationConfig class should contain only things like HTTP port and database connection strings, there should be no entries related to what component, controller, repositories (etc.) the application is using. User application classes should call this.controller(), this.repository() (etc.) to register their artifacts, and eventually use the new bootstrapper module.

• Update our docs for extension developers to describe this as a best practice

• Enhance app.component, app.controller and other related APIs to accept an array of constructors too (or create a new API). This way users don't have to repeat the method call for each entity they are registering.

• Review all code examples in our documentation on loopback.io and fix it to follow the new way

• Update the templates used by our CLI

• Update all other repositories

  • (monorepo) loopback4-example-getting-started
  • (monorepo) loopback4-hello-world
  • (monorepo) loopback4-example-log-extension
  • (monorepo) loopback4-example-rpc-server
  • https://github.com/strongloop/loopback-next-hello-world (deprecated)
  • https://github.com/strongloop/loopback4-extension-starter (deprecated)
  • https://github.com/strongloop/loopback-next-example (not affected)
  • https://github.com/strongloop/loopback4-example-getting-started (deprecated)
  • https://github.com/strongloop/loopback4-extension-grpc
  • https://github.com/strongloop/loopback4-extension-typeorm (deprecated)
  • https://github.com/strongloop/loopback4-extension-mqtt (not affected)
  • https://github.com/strongloop/loopback4-extension-graphql (not affected)
  • https://github.com/strongloop/loopback4-example-log-extension (deprecated)
  • https://github.com/strongloop/loopback4-example-rpc-server (deprecated)
  • https://github.com/strongloop/loopback4-example-hello-world (deprecated)

[shimks]

@bajtos @kjdelisle Are the implementation of configs for port and database connection string out of scope for this task? Nevermind, those already exist within servers

[bajtos]

@shimks We have deprecated some of the example repositories recently. Their GitHub projects are archived and read-only now, there is no need to keep them up-to-update anymore. Basically anything that's in strongloop-archive organization is no longer maintained.

I am not sure what to do about https://github.com/strongloop/loopback4-example-microservices (formerly loopback-next-example). The last time I worked with that codebase, it didn't even compile against the current version of LB4 dependencies. I am proposing to timebox any work on this repository, for example to 2 hours or a half-day at most. There are already some existing issues and pull requests, please update them accordingly after you are done:

• example doesn't run strongloop/loopback4-example-microservices#76
• Update examples to work with latest loopback versions strongloop/loopback4-example-microservices#78

@kjdelisle thoughts?

[shimks]

@bajtos There's no changes that need to be made in loopback4-example-microservices, so we're good with that repository for now.

[shimks]

With comment from @virkt25 in mind (#975 (comment)), I'd like to close the issue as done.

I will create a separate issue (#990) for the discussion of whether the following requirement is necessary or not:

Enhance app.component, app.controller and other related APIs to accept an array of constructors too (or create a new API). This way users don't have to repeat the method call for each entity they are registering.