Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bajtos opened this Issue Oct 26, 2018 · 10 comments

Comments

Projects
None yet
8 participants
@bajtos
Copy link
Member

bajtos commented Oct 26, 2018

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
    • HasOne #1422
    • HasManyThrough #2264
    • 馃毝HasAndBelongsToMany #2308
    • Polymorphic
    • EmbedsOne
    • EmbedsMany
    • ReferencesMany
  • 馃毝CLI for model relation #1359
  • Further REST layer improvements #1452
    • streaming requests/responses
    • handling file uploads #1873
  • 馃毝Plain JavaScript experience #560
  • 馃毝Authentication #1035 (plus a bunch of other stories, e.g. #1334)
  • Authorization #538
  • Include related models in query results (#1352, #1721, #1889)
  • Model migration (in LB 3.x scope) #487
  • 馃毝Model discovery (in LB 3.x scope) #1949
  • From model definition to REST API with no repository/controller classes #2036 #565
  • Boot scripts #2034
  • Middleware: #1293, #2035, #1982. Possibly more.
  • Operation hooks: #1919

See also a loosely related Migration from LoopBack 3.x

@bajtos bajtos added the epic label Oct 26, 2018

@raymondfeng

This comment has been minimized.

Copy link
Member

raymondfeng commented Oct 26, 2018

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

This comment has been minimized.

Copy link
Contributor

dhmlau commented Dec 7, 2018

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

This comment has been minimized.

Copy link

aharbis commented Dec 7, 2018

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

This comment has been minimized.

Copy link
Member Author

bajtos commented Dec 10, 2018

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

@ambrt

This comment has been minimized.

Copy link

ambrt commented Dec 11, 2018

I'm all for Authentication & Authorization.

@bajtos bajtos referenced this issue Dec 11, 2018

Open

Best practice for encrypting model properties #2095

0 of 3 tasks complete
@bbenejc

This comment has been minimized.

Copy link

bbenejc commented Dec 11, 2018

For me, the most important ones:

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

This comment has been minimized.

Copy link

yagobski commented Dec 20, 2018

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

@bajtos

This comment has been minimized.

Copy link
Member Author

bajtos commented Feb 4, 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 #2036
  • CLI for model discovery in LB4 #1949
@luisfavila

This comment has been minimized.

Copy link
Member

luisfavila commented Feb 5, 2019

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

This comment has been minimized.

Copy link
Contributor

dhmlau commented Mar 16, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.