Feature parity with LoopBack 3.x (and the lack of it)

[bajtos]

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.

• More relations [EPIC] More Relations (post-GA) #1450
  • HasOne [Relation] Supports HasOne relation #1422
  • HasManyThrough Model relation: hasManyThrough #2264
  • 🚶HasAndBelongsToMany [Model Relation] hasAndBelongsToMany #2308
  • Polymorphic Polymorphic relation type #2487
  • EmbedsOne
  • EmbedsMany
  • ReferencesMany feat: adds support ReferencesMany relation #8271
• CLI for model relation [CLI] add lb4 relation command #1359
• Further REST layer improvements [EPIC] REST layer improvements (post-GA) #1452
  • streaming requests/responses
  • handling file uploads File upload with multipart/form-data #1873
  • Express Middleware: Allow app developers to configure custom Express middleware #1293, Register Express middleware per route, controller class or controller method #2035, Tutorial/Blog: how to mount LB app as Express/Koa middleware #1982. Possibly more.
• 🚶Authentication Authentication and Authorization extension points #1035 (plus a bunch of other stories, e.g. Document ways to properly authenticate only some methods in a controller #1334)
• Authorization Extension: Add Authorization component #538
• Include related models in query results (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)
  • A note on findById: 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).
• Model migration (in LB 3.x scope) Easy-to-use database migrations at application level #2059 (further work beyond LB3 scope: Database Migration Management Framework #487)
• Model discovery (in LB 3.x scope) CLI for model discovery in LB4 #1949
• From model definition to REST API with no repository/controller classes From model definition to REST API with no custom repository/controller classes #2036 Declarative Support #565
• Boot scripts Boot scripts #2034
• Operation hooks: Spike: Operation hooks for models/repositories #1919
• Plain JavaScript experience [ON HOLD] Plain JavaScript experience #560

See also a loosely related Migration from LoopBack 3.x

[raymondfeng]

A few more features in LB3.x but missing in LB4.x:

1. A simple way to generate REST APIs for models (datasource + model + controller)
2. Boot scripts
3. Middleware

[dhmlau]

Hi everyone, we've identified the feature parity gap as listed above and created separate issues in loopback-next repo. 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

1. Review the feature parity gap list in the original description of this issue
2. 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

[aharbis]

Some of the big hitters here that are blocking us from migrating from LB3 to LB4 would be:

• Polymorphic relations. Specifically, we leverage polymorphic belongsTo mostly. 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 include filter heavily, as we leverage relations heavily in our application. The front-end we have depends on being able to easily set include to get related model instances. One example would be querying for a User and setting include: 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 Loader model 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 AccessToken and our own "user" model that inherits from User. 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. Authorization or 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 the userId from ctx.req.accessToken. We don't necessarily need that resolution to migrate, but having the ground work laid for a new AccessToken and 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.

[bajtos]

@aharbis thank you for the list of things that's blocking your project(s) to migrate to LB4, this is very helpful!

[ambrt]

I'm all for Authentication & Authorization.

[bbenejc]

For me, the most important ones:

• HasOne relations
• Polymorphic relations
• Authentication
• Authorization
• Include related models in query results

[yagobski]

API auto generation was the most powerful feature for LB3 that missing with LB4

[bajtos]

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

[luisfavila]

I was surprised to find juggler's upsert and upsertWithWhere to 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?

[dhmlau]

@bajtos @raymondfeng , do you have any concerns of adding upsert and upsertWithWhere as @luisfavila mentioned? Thanks.

[aharbis]

@bajtos Should #2487 be linked to Polymorphic in the top comment? Is that the best issue to track the Polymorphic feature with?

[hazimdikenli]

I think Authentication and Authorization are the most important ones, along with fileUploader.

[collaorodrigo7]

A few more features in LB3.x but missing in LB4.x:

1. A simple way to generate REST APIs for models (datasource + model + controller)
2. Boot scripts
3. Middleware

Hey @raymondfeng with number 1 you mean, the feature that will create all CRUD endpoints for a model automatically and will execute the necessary queries for each of them? (Like you create a PersistedModel and you will automatically get insert, edit, delete, read?)
Where would you suggest me to start looking if I would like to help with that?

[bajtos]

@collaorodrigo7

1. A simple way to generate REST APIs for models (datasource + model + controller)

with number 1 you mean, the feature that will create all CRUD endpoints for a model automatically and will execute the necessary queries for each of them? (Like you create a PersistedModel and you will automatically get insert, edit, delete, read?)

While I cannot speak for Raymond, we have an Epic tracking the feature you are looking for, see #2036 From model definition to REST API with no repository/controller classes

Where would you suggest me to start looking if I would like to help with that?

I think #2736 would be a great first step to make. See "Acceptance criteria" in #2036 for the next steps.

[enceladus]

I just wanted to offer a suggestion here.

It was only after developing an app for a while for a client that I discovered this lack of feature parity, mostly due to the misleading documentation on the website — the LB3 docs suggest "use LB4 if you are new" and the LB4 docs don't suggest anywhere that major features I had expected in GA were missing (authorization mostly, but also #1450 and #1352).

Of course, I should have done my research. But I think some sort of disclaimer somewhere on the LB4 landing page or documentation index about the shortcomings here would save a lot of headaches. It didn't take more than three days to redo my work in LB3, thankfully, but it was a setback.

[achrinza]

Just checking in; can we mark Authorization, Authentication and #1035 as done? The related issues seems to be closed and there hasn't been much recent discussion.

[csvan]

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.

[achrinza]

this 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.

[csvan]

@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.

[raymondfeng]

@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.

[dougal83]

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. 👨‍🔬

[jseb16]

Just 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

[achrinza]

@jseb16 It's updated; the focus right now is more towards improving SQL relations.

[jseb16]

Great, it looks really promising.

[raman1212]

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.

[achrinza]

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.

[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.