-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migration from LoopBack 3.x #1849
Comments
Cross posting my earlier thoughts - please note some parts are outdated and need tweaks to make them compatible with the latest LB4 design. Here are my thoughts on the migration story. At high-level, LoopBack 3.x applications consist of three big "parts"
In the persistence layer, users can contribute the following artifacts:
At the public API side, users can define:
LoopBack Next was intentionally designed to allow users to choose their ORM/persistence solution, and our initial version of The proposalHere is my proposal:
A simplified example: @api({basePath: '/products'})
export class ProductController {
constructor(
@inject('models.Product') private Product: Entity
){}
@get('/')
@param.query.object('where')
// TODO describe response type
find(where: Object): Product[] {
return await this.Product.find(where);
}
@get('/custom')
// ...
customMethod(arg: number): Object {
return await this.Product.customMethod(arg);
}
@patch('/{id}')
// ...
prototypeUpdateAttributes(id: number, data: Partial<Model>) {
const instance = await this.Model.sharedCtor(id);
return await instance.updateAttributes(data);
}
// ...
} Remoting hooksLet's talk about remoting hooks now and how to translate them to LB Next:
@api({basePath: '/products'})
export class ProductController {
constructor(
@inject('models.Product') private Product: Entity
){}
before(route: Route, args: OperationArgs) {
console.log('Invoking remote method %s with arguments %s',
route.describe(); JSON.stringify(args));
}
@get('/')
@param.query.object('where')
find(where: Object): Product[] {
console.log('Here we can modify `where` filter like we were in a before-remote hook');
return await this.Product.find(where);
}
// etc.
} I don't think we can automate this migration step, because remoting hooks expect to receive a strong-remoting context that we don't have in LoopBack next. A good documentation with helpful examples is needed. Alternatively, we can let the controller to provide class MyController {
invokeMethod(route: Route, args: OperationArgs) {
console.log('Invoking remote method %s with arguments %s',
route.describe(); JSON.stringify(args));
return await this[route.methodName](...args);
}
}
// alternate invokeMethod implementation supporting before/after/afterError hooks
// this can be a Controller Mixin provided by an extension
invokeMethod(route: Route, args: OperationArgs) {
if (this.before)
await this.before(route, args);
try {
const result = await this[route.methodName](...args);
if (this.after)
result = await this.after(route, args, result);
return result;
} catch(err) {
if (this.afterError)
const handled = await this.afterError(route, args, error);
if (handled) return;
}
throw err;
} Summary:
Remaining things to figure out:
Possibly out of scope:
Next level
JustificationYou may ask why to code-generate all those controller files? In my experience, one of the most frequently sought feature of LB 3.x is the ability to control and customize the public API. Users start with a wide built-in CRUD API provided by the LoopBack, but soon enough then need to lock the API down, expose only subset of endpoints, and customize how exactly these endpoints work. In LoopBack 3.x, this was a complex process that required hooks at many different levels (middleware/strong-remoting phases, remoting hooks, operation hooks) and unintuitive API like In my proposal, customization of the REST API is as easy as editing the generated code.
Remaining things to figure out:
Possibly out of scope:
Next level Migrate LB 3.x .json and .js files to use @loopback/repository. The generated controllers should use typed Repositories instead of juggler 3.x based Model classes. |
I have some initial ideas as follows:
|
@bajtos , @raymondfeng for CRUD,
In other words, we can run a command inside an lb3 app like so:
The CLI could read the datasources, models, hooks for CRUD and generate the appropriate files. thoughts? |
any progress about this task. How we can migrate large app from LB3? |
For everybody watching this issue: please take a look at my proof-of-concept in #2274, it shows a compatibility layer allowing LB3 models to be added to LB4 applications and exposed via LB4 REST layer, with (hopefully) no changes in the LB3 model scripts needed I would appreciate your feedback.
Please leave your comments in the pull request, not here. |
In #2318, I am showing a different approach where the entire LB3 application (including it's runtime dependencies in LTS mode) is mounted on an LB4 application and the Swagger/OpenAPI specifications are merged to produce a single unified spec describing both LB3 and LB4 endpoints. Would you find this feature useful and start running your LB3 application mounted in an LB4 app? |
Created more stories:
|
Current status: It's possible to take an existing LB3 application and add it as-is to an LB4 project. See https://strongloop.com/strongblog/migrate-from-loopback-3-to-loopback-4/ and https://loopback.io/doc/en/lb4/Migrating-from-LoopBack-3.html. While this does not remove dependencies on LB3 runtime, we hope it will make it easier for you to incrementally migrate your LB3 code to LB4. |
Thank you @Sumit0581 for sharing your solution with us. Recently, @raymondfeng added support for Lifecycle observers (see docs), I believe they are intended to replace boot scripts. They are actually better than LB3 boot scripts, because they allow you to run some code not only at app startup, but also when the app is shutting down. |
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 |
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 |
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 |
code: 'ER_NOT_SUPPORTED_AUTH_MODE', i am using |
When LoopBack 4 gets more mature and reaches feature parity with LoopBack 3, we should write a migration guide and automated tooling to help existing LoopBack 3 users to upgrade their projects to LoopBack 4.
Spike tasks:
The text was updated successfully, but these errors were encountered: