Closed bajtos closed 3 years ago
@bajtos In addition to what you have listed, I also have the following requirements in mind:
The ability to expose an extension point to allow customization of a service and fall back to a default implementation. For example, a user management
component by default uses bcrypt
for password hashing but it should allow an optional
external binding for the hashing function.
The ability to organize artifacts as extension points/extensions, for example, bootstrapper -> booters, authenticator -> strategies, rest -> servers, even app -> components. The extension point should be able to depend on a list or map of extension instances for delegation. Each extension point and extension should be able to receive corresponding configurations.
The ability to maintain isolated and connected contexts for an app, a component, or an extension point.
@raymondfeng thanks, I'll add you items to the top-level description. I think the scope of this issue has overgrown the size of a single user story, I am going to change this issue to an epic.
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.
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.
List of issues in the current design of Extensions:
Writing an extension class requires a lot of hand-written glue. The developer has explicitly list all controllers, bindings, etc. they want to add to the app. We should have a conventional bootstrapper that can scan filesystem and discover entities to add to the app automatically. Ideally, most of the conventions should be same for applications and extensions, so that LoopBack users have only one set of conventions to learn, and the bootstrapper package has only one set of conventions to implement.
Adding support for new type of entities that can be contributed by extensions requires changes in several places. For example, we already have API for binding classes (
app.bind('foo').toClass(Foo)
), but components cannot leverage it untilapp.component()
is updated to support it as well.Even though it's easy for a component to contribute Providers for DI, the extension cannot control binding settings like scope (SINGLETON), tags, etc.
I think we should step back to the drawing board, build/update the requirements (a list of things extensions typically want to accomplish), and come up with the best solution that will support these requirements while making developer experience superb.
More requirements to keep in mind:
The ability to expose an extension point to allow customization of a service and fall back to a default implementation. For example, a
user management
component by default usesbcrypt
for password hashing but it should allow anoptional
external binding for the hashing function.The ability to organize artifacts as extension points/extensions, for example, bootstrapper -> booters, authenticator -> strategies, rest -> servers, even app -> components. The extension point should be able to depend on a list or map of extension instances for delegation. Each extension point and extension should be able to receive corresponding configurations.
The ability to maintain isolated and connected contexts for an app, a component, or an extension point.