Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC: use LB3 models in an LB4 app [SPIKE - DO NOT MERGE] #2274
In this pull request, I am presenting a proof-of-concept showing how we can enable LB3 users to take their model files (JSON + JS), drop them mostly as-is into an LB4 application and get a fully working LB4 REST API mostly compatible with their own old API as provided by LoopBack 3.
The proposed compatibility layer will greatly simplify migration from LoopBack 3 to LoopBack 4. Instead of forcing users to migrate everything in one go, the new layer makes it possible to split the migration into multiple incremental steps:
Feedback wanted from current LoopBack 3.x users
I would like to get feedback from developers maintaining a LoopBack 3 application and looking for a way how to migrate to LoopBack 4.
How to review this work
Discussion points (primarily for LoopBack maintainers)
requested review from
Jan 22, 2019
@bajtos Thank you for kicking it off with fairly comprehensive code. I think existing LB3 users will love it if we do it right.
In addition to the
@bajtos, this looks pretty interesting! I'm wondering if it's not easier to require an lb3 app in it's entirety as a dependency and boot the apps together.
While the tests on a lb3 app can be ported over fairly easily, I would be concerned about my case coverage and how well I've tested all of the side effects and coupling between models in my legacy application (I would love to say that I never do this... But I suspect that I'm not alone here).
Can I expect that everything will just work the same way out of the box?
Interesting idea, I haven't considered it before.
When using an existing LB3 app in whole, then we need to bring in
With my proposed "compat" package, upgrading users are moving completely away from the old npm modules and use LB4 counterparts instead.
Hey, nice to see you again :)
Haha, that's what @raymondfeng proposed too. Would you find such solution useful even if it does not buy you any extra time before you have to move away from LB3 anyway?
Kind of. Setting the known differences aside (no Bluebird API, different coercion rules at REST API layer), the rest should work the same way out of the box. Unfortunately, we cannot guarantee that - LoopBack test suite does not cover all edge cases either. We need user feedback to let us know where the compatibility layer behaves differently from LB3, so that we can incrementally and iteratively improve it.
This also allows us to spend our time on things that matter for real users, instead of trying to chase edge cases that exist in theory but nobody cares about in practice.
Absolutely useful. Sure, LB3 LTS will eventually end, but that doesn't necessarily mean that I'm going to upgrade either. There are still people out there using versions of Node that have long left LTS.
What I don't like is the idea of jumping back and forth between two different configurations where half my models are configured one way and the other half are configured another way. I would rather bundle a legacy application with say,
As @raymondfeng suggests, it would also be very useful to have a unified OpenAPI spec doc, but I'm not sure how messy that would get.
Take everything that I'm suggesting with a grain of salt. I use LoopBack 3 to build very small microservices where porting everything over to LB4 would not take that much work. I think that it would be beneficial to talk to someone who has a larger application to see what their opinion is.
referenced this pull request
Jan 29, 2019
referenced this pull request
Jan 31, 2019
We have one LB3 app running in production right now and we would very much like to upgrade it to LB4. The ability to do this incrementally would be super nice. However, it seems to me that the current POC implementation may not provide sufficient functionality just yet.
A few issues / questions:
First, it seems the POC currently does not support remote hooks. Those are absolutely "must-haves" for us. Our code relies on them.
We also need relations to work properly. I'm not sure if the POC covers these completely. We define them in JSON and we don't really use much of the related JS APIs. Would this work with the compatibility layer?
What about authentication? We are using the built-in LB3 user model and auth token system. I know something similar (a JWT token based auth solution) is in the works for Loopback 4 right now, but I'm not sure what's the status of this and when can we expect the first stable version to be released.
What about plugins / 3rd party packages? :) We have only a few, such as softdelete mixin, pagination mixin, loopback-component-storage etc. Guess we can expect these to break, right? Or would the compatibility layer support these as well?
We are using MongoDB, but I guess that's covered by database-juggler 4.x, right?
So these are the most important features our app needs. Will the compatibility layer cover these anytime soon?
By the way, obviously the compatibility layer will be pretty useful, but not only because it allows incremental migration. If it includes all the the truly essential functionality and you manage to extend its lifespan, it could also buy enough time for LB4 to "catch up".
I mean, LB4 is really great. It's a very nice architecture, but - for now at least -, it's mostly core functionality. A lot of important stuff is missing which people will have to write as extensions. The community needs time to do this.
On the other hand, LB3 already provides most of these functions / tools (either as part of its core or as some widely used 3rd party packages).
So in my opinion, running a proper compatibility layer with LB4 has additional benefits. It could provide production ready, proven solutions that people could actually use while the LB4 counterparts of these solutions are under development. As new LB4 extensions become available, the old stuff could be replaced.
Anyway, just some additional thoughts I wanted to share :)
@gtamas thank you for the feedback, I appreciate it a lot!
I believe relations will work. I don't have the code in place yet, but I think the implementation should be easy enough. In my plan for v1, relations are included.
Ah, this is tricky. The way how I am envisioning the compatibility layer, there will be no built-in models for authorization - but you may be able to copy them over from the old LoopBack. We will need to look into ways how to plug LB3 AccessToken into LB4 authentication & authorization mechanisms. Those mechanisms are not fully fleshed out yet and we don't have any ETA, the work is going slower that we anticipated.
I think it should be possible to support mixins. We may need a bit of research to find out how to load & register them in the same way as LB3 does, but I think it will be doable.
As for loopback-component-storage, it's working more like a connector than a typical component, isn't it? I mean it's configured via
Honestly, the compatibility layer is a lot of work, my rough estimate is that it will take months to complete. Would you like to join the effort and contribute some parts yourself?
For near-term, we are planning to start with a slightly different approach that will be faster to implement, see #2318.
b-admike left a comment •
Lots of code to review (not super familiar with strong-remoting and other areas of compat layer), but I get the gist of the spike and I like how well you've put it together and the direction we are heading. Especially after reading the architectural overview, the design and mapping sounds reasonable
This IMO is dependent on how fast we can get the compat layer up and running for users to migrate from LB3 to LB4 while we bridge the feature gaps in LB4. From this PoC, I feel like this makes migration easier and can be hopefully done in months and not years so that it gives way to smooth migration and allows us to work on feature parity in the meantime.
I think the commits follow a logical progression, but if we can use the architectural overview to break them up (like how the sections are there), then it'd be awesome.
This could possibly be a spike story to investigate those two challenges.
I don't have better suggestions at the moment.