Spikes for extension infrastructure

[dhmlau]

Per discussion with @kjdelisle and @raymondfeng, created this epic.

• to make sure we have consistent extension points/extension
• Raymond has a few PRs created

Scope (for 4.0 GA)

For GA, do a spike story to confirm feasibility of each of the following extension use cases:

• Custom booters - [Spike] Allow extensions to contribute custom booters #1461
• Custom authorization providers & strategies - [Spike] Allow extensions to contribute custom authorization providers and strategies #1462
• Custom validators and serializers/deserializers for REST layer - Spike: allow extensions to contribute custom validators and serializers/deserializers for REST layer #1463
• How to apply environment-specific operational configuration - [Spike] Allow extensions to contribute custom convention for environment-specific operational configuration #1464

[raymondfeng]

Related issues:

• Improve Extension authoring #953
• Authentication and Authorization extension points #1035

Related PRs:

• Extensibility

  • [WIP] feat(core): Add support for extension point/extension pattern on top of Context #657 (Implement extension point/extension pattern with Context)
  • [WIP] feat(context): a better/simpler way for binding configuration and @inject.config #983 (Add configuration for extension points/extensions)

• Composability:

  • [WIP] feat(context): add @injectable to decorate bindable classes #992 (Allows extension points/extensions to be decorated with corresponding metadata)
  • [WIP] feat(context): Allow components to expose a list of bindings #929 (Allow a component to expose a list of bindings)
  • [WIP] Improve composablity of Context with multiple delegates #882 (Allow multiple contexts to be composed into a hierarchy)
  • [WIP] [RFC] Allow sequence to be composed from actions with class/method dependency injection #713 (Allow automatic composition of actions)

[raymondfeng]

Some context from the @loopback/boot discussion:

A typical LoopBack 4 application will be composed from multiple components. A component is the basic unit and it has both deployment and runtime views. The deployment view is module while the runtime view is context. A component can be the main application module, an embedded local module, or an installed npm module. I want to have main component to represent the application module to make it consistent. The relation is illustrated below:

Each component can have declarative artifacts as well as programatic contributions. The bootstrapper can boot components so that declarative constructs can be populated in the context. The boot process connects the deployment view to the runtime view.

The Application coordinates the composition of components. For example, app.boot() will locate a list of components (including the main one by the application module) and use the Bootstrapper to boot the components. Please note each component has a reference to the containing module and corresponding metadata from package.json or other files. The module metadata provides configuration such as project root and project layout version for the boot. An instance of Context is created per component. After boot, the component context is fully populated. The application can then compose all component contexts into app context (by merging or delegations).

[stale]

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]

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.