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