Loopback-next: 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 #1450
  
  
  
  • [x] HasOne #1422
  
  
  • [x] HasManyThrough #2264
  
  
  • [ ] 🚶HasAndBelongsToMany #2308
  
  
  • [ ] Polymorphic #2487
  
  
  • [ ] EmbedsOne
  
  
  • [ ] EmbedsMany
  
  
  • [ ] ReferencesMany
  
  
• [x] CLI for model relation https://github.com/strongloop/loopback-next/issues/1359
• [ ] Further REST layer improvements #1452
  
  
  
  • [ ] streaming requests/responses
  
  
  • [x] handling file uploads #1873
  
  
  • [x] Express Middleware: #1293, #2035, #1982. Possibly more.
  
  
• [x] 🚶Authentication #1035 (plus a bunch of other stories, e.g. #1334)
• [x] Authorization #538
• [x] Include related models in query results (#1352, #1721, #1889)
  
  
  
  • _A note on findById: filtering was enabled by #4114. The task #1721 somewhat optional, it mostly improves the type descriptions (TypeScript, OpenAPI schema)._
  
  
• [x] Model migration (in LB 3.x scope) https://github.com/strongloop/loopback-next/pull/2059 (further work beyond LB3 scope: https://github.com/strongloop/loopback-next/issues/487)
• [x] Model discovery (in LB 3.x scope) https://github.com/strongloop/loopback-next/issues/1949
• [x] From model definition to REST API with no repository/controller classes #2036 #565
• [x] Boot scripts #2034
• [ ] Operation hooks: #1919
• Plain JavaScript experience [ON HOLD] #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 (#1722). We leverage PATCH operations heavily in our front-end for ease of use. Our API consumers also expect this functionality.
• Include filter (#1352, #1721, #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, #1352 and #1721 are more important to me than #1889.
• File uploads (#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 (#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 #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 #2036
• 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 https://github.com/strongloop/loopback-next/issues/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 https://github.com/strongloop/loopback-next/issues/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. :man_scientist:

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