Repository navigation
Feature parity with LoopBack 3.x (and the lack of it) #1920
Description
Activity
A few more features in LB3.x but missing in LB4.x:
- A simple way to generate REST APIs for models (datasource + model + controller)
- Boot scripts
- Middleware
Reacted by Mathieu DARTIGUES and Akash JaradHi everyone, we've identified the feature parity gap as listed above and created separate issues in
loopback-nextrepo. We'd like to hear from you about which one you'd like to see first, so that it helps us decide. :)How it works
- Review the feature parity gap list in the original description of this issue
- For the one you'd like to see first, upvote it. Of course, feel free to comment.
What if my wishlist is not on this list?
Create a new issue in this repo and put a comment in this issue.
How do I see which ones are popular requests from the community?
If everything goes right, we should be able to see it from this query: https://github.com/strongloop/loopback-next/issues?q=is%3Aopen+label%3A%22feature+parity%22+sort%3Areactions-%2B1-desc
cc @strongloop/loopback-next @strongloop/loopback-maintainers
Reacted by Aidan HarbisonSome of the big hitters here that are blocking us from migrating from LB3 to LB4 would be:
- Polymorphic relations. Specifically, we leverage polymorphic
belongsTomostly. This is a critical and heavily used part of our application architecture. I'd much rather leverage a LB4 native polymorphic relation versus trying to build one ourselves. I don't see an open issue for this specifically; I'm happy to open one if that will help. - Patch support (Partial update (PATCH) over REST #1722). We leverage PATCH operations heavily in our front-end for ease of use. Our API consumers also expect this functionality.
- Include filter (Inclusion of related models [MVP] #1352, Add support for "include" and "fields" to findById (REST API) #1721, Include related models in "GET /mymodels" results #1889). We utilize the
includefilter heavily, as we leverage relations heavily in our application. The front-end we have depends on being able to easily setincludeto get related model instances. One example would be querying for aUserand settinginclude: roles. Of the tagged issues, Inclusion of related models [MVP] #1352 and Add support for "include" and "fields" to findById (REST API) #1721 are more important to me than Include related models in "GET /mymodels" results #1889. - File uploads (File upload with multipart/form-data #1873). We support a
Loadermodel in our application which allows users to load the database with model instances through a file uploader. This is a critical step for onboarding new teams to our application as users, or migrating legacy data to the cloud app. - Authorization (Authentication and Authorization extension points #1035). We currently have our own "token" model that inherits from
AccessTokenand our own "user" model that inherits fromUser. With these two models we build our authorization stack and manage user sessions. At the very least we'd need a way to leverage either query params (in LB3 ex.?access_token=<token>) or headers (ex.Authorizationor Bearer token). It's very nice that in LB3 the LB framework automatically resolves the token when provided so in a remote hook (for example) we can directly access theuserIdfromctx.req.accessToken. We don't necessarily need that resolution to migrate, but having the ground work laid for a newAccessTokenand middleware to handle the params/headers would be really nice. I see Groundwork: Access tokens, login & logout #1997 might be a good match for this.
Hope this helps. I'm happy to go into any further detail. The above certainly isn't our full list, but these are the big ones that would keep us from migrating. A lot of the other items we've identified as gaps we could work around while the LB team adds the features.
Reacted by Sylvain Dumont, Biniam Admikew, Joost de Bruijn, hvlawren, shadyanwar, Miroslav Bajtoš, Mehari, Diana Lau, Félix, Shing. and 11 moreReacted by Shing., L. Bete, heliortf, Johnny Driesen and Roger Kermode- Polymorphic relations. Specifically, we leverage polymorphic
I'm all for Authentication & Authorization.
Reacted by Diana Lau, Laurent, Benjamin Kroeger, heliortf, John Tomaselli, Faouzi EL YAGOUBI, cengiz-dev, Vamsi Kotipalli, John Lindahl and sertal70Reacted by Laurent, heliortf, John Tomaselli and Faouzi EL YAGOUBIFor me, the most important ones:
- HasOne relations
- Polymorphic relations
- Authentication
- Authorization
- Include related models in query results
Reacted by Diana Lau, Daniel Täge, Samarpan Bhattacharya and Dan JarvisAPI auto generation was the most powerful feature for LB3 that missing with LB4
Reacted by collaorodrigo7, Mathieu DARTIGUES, heliortf, Ben Painter, Faouzi EL YAGOUBI, Andres Rodriguez and yongzhi-chen- pinned this issue
on Jan 11, 2019 API auto generation was the most powerful feature for LB3 that missing with LB4
FWIW, I believe this is covered by the following two issues:
- From model definition to REST API with no repository/controller classes From model definition to REST API with no custom repository/controller classes #2036
- CLI for model discovery in LB4 CLI for model discovery in LB4 #1949
I was surprised to find juggler's
upsertandupsertWithWhereto be missing in LB4 though it could be easily implemented at repository level. Would you like me to implement it in loopback core or should it be left out?Reacted by Zakaria Mansouri and Juan Gutiérrez@bajtos @raymondfeng , do you have any concerns of adding
upsertandupsertWithWhereas @luisfavila mentioned? Thanks.I think Authentication and Authorization are the most important ones, along with fileUploader.
Reacted by Oussama Bouthouri, Torgeir Hovden and sertal704 remaining items
Like @enceladus , I discovered how gutted lb4 was in terms of features over earlier versions while already committed to a project. I know this is no excuse for not doing adequate research, but I came back to LB after using LB2 (and loving it) on another project some years back. I was not at all prepared for pretty much everything being removed in LB4. I spent a good 5 hours implementing basic auth, only to discover that almost all the built-in relations are gone as well. Implementing them manually comes with its own overhead.
Only option I see right now to keep the pace with LB is to drop the current implementation and go back to LB3. However, since that is in LTS mode, I would be opting for a dying major version that we need to migrate in the near future anyway. As such, I am unfortunately having to evaluate moving
to a different solution altogether.Seriously, I deeply appreciate your work, but this NEEDS a massive disclaimer right on the front page. "Production ready" is unfortunately simply misleading at this point - LB4 is great but should have been in Beta until parity is achieved.
Reacted by Joost de Bruijn, Rizz, rahpuser and Srirang Rthis NEEDS a massive disclaimer somewhere
@csvan Sorry to hear about your experience. While I can't comment on behalf of the core maintainers, #4466 was meant to resolve @enceladus' issue by adding a disclaimer to the documentation's home page. Unfortunately it seems to not have been suffice.
@achrinza I appreciate that and have rephrased my criticism. It may be ugly, but perhaps it would be worth having this warning on the "Getting Started" sections for LB4? Specifically:
https://loopback.io/getting-started.html
and
https://loopback.io/doc/en/lb4/Getting-started.html
Perhaps display something like
WARNING: If you have worked with Loopback 2.x or 3.x, please note that Loopback 4.x does not have full feature parity with these, and you may miss functionality included in earlier versions. Please follow #1920 for updates.
Reacted by Rizz and mikeevstropov@csvan Sorry for hearing that you have some pains in implementing LB3 features in LB4. Please check the migration guide at https://loopback.io/doc/en/lb4/migration-overview.html to see some concrete steps/examples.
Personally, as it is informational I'd go with the following:
NOTE:
Please be aware that Loopback 4.x is implemented on an entirely new base and therefore does not have full feature parity with previous versions. Please see #1920 to compare the current feature set in relation to Loopback 3.x.Although it still relies on people doing their research and reading first though. 👨🔬
Reacted by Christopher Svanefalk, Dominique Emond and Ilia SmirnovJust checking if these feature list is updated.
Interested in knowing if embedOne and emberMany is available in Lb4 and also if there are more resources available for getting into lb4
@jseb16 It's updated; the focus right now is more towards improving SQL relations.
Reacted by Sebastian Gomez, Rizz, Douglas McConnachie and Axell BrendowGreat, it looks really promising.
one another thing is we can not use a table with name "my_data" in loopback 4 but can be used in loopback 3 as loopback 4 do not allow model with underscore name.
one another thing is we can not use a table with name "my_data" in loopback 4 but can be used in loopback 3 as loopback 4 do not allow model with underscore name.
Please see https://stackoverflow.com/a/62281311/5019371.
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
CODEOWNERSfile 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
CODEOWNERSfile at the top-level of this repository.
This epic is keeping a track of features that are available in LoopBack 3.x but don't have an easy-to-use alternative in LoopBack 4.x.
lb4 relationcommand #1359findById: filtering was enabled by feat(cli): update controller template to enable filter for findById endpoint #4114. The task Add support for "include" and "fields" to findById (REST API) #1721 somewhat optional, it mostly improves the type descriptions (TypeScript, OpenAPI schema).See also a loosely related Migration from LoopBack 3.x