Loopback-next: [Roadmap] 🚀1Q2019 🚀

[dhmlau]

This is a high-level issue keeping track of deliverables in the next 90 days.
_Please note that this is our plan for the roadmap and it is subject to change._

_UPDATE (11/19)_:

• Included more details in the authentication story
• Added hasOne model relation type based on user feedback
• Add stories around user adoption, e.g. how to mount LB4 as middleware, plain JS experience.
• Removed the juggler-next story. The plan is to see if we can enhance the Repository level without rewriting the juggler

Overview

• Focus on helping out early adopters (users + contributors)
• Continue to use scenario driven approach to drive requirements
• Keep monthly milestones and provide overview what we're going to deliver

Scope

_See the current list of stories: https://github.com/strongloop/loopback-next/labels/TOB_

Authentication and Authorization https://github.com/strongloop/loopback-next/issues/1035

• [x] Refactoring: Customer credentials, #1996
• [x] Groundwork: Access tokens, login & logout,  https://github.com/strongloop/loopback-next/issues/1997
• ~[ ] The First Scenario: Authenticated orders (a minimal authentication), https://github.com/strongloop/loopback-next/issues/1998~ out of scope for Q1

Self-hosted API Explorer https://github.com/strongloop/loopback-next/issues/559

• [x] Error handling for non-API routes #1784
• [x] Invoke serve-static after API router #1785
• [x] Support local API Explorer, #1960
• [x] A self-hosted API Explorer as a new extension #2014

Deployment to IBM Cloud

• [x] k8s based deployment with IBM Cloud https://github.com/strongloop/loopback-next/issues/1606

Unified web site experience https://github.com/strongloop/v4.loopback.io/issues/52

• [x] Change banner for loopback.io documentation site and apidocs.loopback.io https://github.com/strongloop/loopback.io/issues/757
• [x] Clean up "Contributing to LoopBack" page, https://github.com/strongloop/loopback.io/issues/758
• [x] Update the contribution page for Loopback 3 https://github.com/strongloop/loopback-next/issues/1673

Documentation cleanup epic https://github.com/strongloop/loopback-next/issues/1951

• [x] LB4 Documents need a cleanup pass https://github.com/strongloop/loopback-next/issues/1908
• [x] [Docs] Relation decorators page should be updated https://github.com/strongloop/loopback-next/issues/1910

User adoption

• [x] Show how to mount LB app to Express/Koa as middleware https://github.com/strongloop/loopback-next/issues/1982

Model relation

• [x] hasOne #1422

Stretch goals

Authentication and Authorization

• The Second Iteration: Cancelling orders (a minimal scope-based authorization), https://github.com/strongloop/loopback-next/issues/1999  

Messaging/Event API https://github.com/strongloop/loopback-next/issues/1884

• first reference implementation to initiate discussion

User adoption

• Plain javascript experience https://github.com/strongloop/loopback-next/issues/560

---

Removed from the original scope

Juggler 4.0 https://github.com/strongloop/loopback-next/issues/890

• [ ] import juggler as-is using lerna import https://github.com/strongloop/loopback-next/issues/1725
• [ ] import subset of connectors as-is 
  
  
  
  • [ ] mysql https://github.com/strongloop/loopback-next/issues/1726
  
  
  • [ ] mongodb https://github.com/strongloop/loopback-next/issues/1727
  
  
  • [ ] rest,  https://github.com/strongloop/loopback-next/issues/1728
  
  
  • [ ] kv-redis https://github.com/strongloop/loopback-next/issues/1729
  
  

[JesusTheHun]

If I may comment this without overstepping...
I'm interested in 2FA, passport & third-party support, but none of it is truly useful until we have an authorization plugin.
I think the authorization plugin should come with the authentication one, and authentication add-ons come after.
Can you add a basic authorization plugin for this milestone ? This will make LB4 usable in the real world.

[dhmlau]

@JesusTheHun , thanks for your feedback!
In fact, we have a PR #1205 for authorization. Is this something you're looking for?

[JesusTheHun]

Yes I look for this kind of component. I've read the PR, is it meant to be merged or is just a RFC/draft ? Either way, can I provide feedback on it ?

[dhmlau]

We'd love to hear your feedback!
We'll discuss the investigation out of this spike and decide what to do. Will post the conclusion on https://github.com/strongloop/loopback-next/issues/1462 or the PR #1205 .

[sbacem]

can you add PostgreSQL in Juggler 4.0 ?
I need this.
and thanks for great job in loopback 4, i love it :heart_eyes: .

[JesusTheHun]

@dhmlau Thank you. I have submitted my feedback.

[bajtos]

@sbacem

can you add PostgreSQL in Juggler 4.0 ?
I need this.
and thanks for great job in loopback 4, i love it 😍 .

We are happy to hear that you like the new version of our framework.

LoopBack 4 is compatible with all existing LoopBack connectors including PostgreSQL, see https://github.com/strongloop/loopback-connector-postgresql

[sbacem]

@bajtos Thanks for the information.

[RaphaelDrai]

Hello dmhlau,
I am interesting to contribute with the Data Relation "hasOne" #1422 .
What is the current status?
Who are the actual contributors that are involved in the coding of this feature that I can contact and collaborate with?
Thanks,
R.D

[dhmlau]

@RaphaelDrai, thanks for the interest. https://github.com/strongloop/loopback-next/issues/1422 is the github issue keeping track of the hasOne relation. From my understanding, it's currently blocked by the findOrCreate task (https://github.com/strongloop/loopback-next/issues/1956), which should be completed pretty soon.

@b-admike is working on both (the blocker and hasOne tasks). I'll leave it to him to decide whether it's a good time to have extra help or he's almost done that it might make more sense to work on a new relation type.

Would you be interested in contribute to other relation type? Looks like there are a few interested parties from https://github.com/strongloop/loopback-next/issues/2043.

[b-admike]

@RaphaelDrai Thank you for asking; There are a few PRs in play (see #1879 #2005 and #1974). The first approach we took was to using atomic operations provided by connectors (specifically findOrCreate) to make sure only one target instance was created for a source instance in a hasOne relation. Since we found out that not all connectors support this, the other option was to use concept of transactions for simulating the atomic operations, but we also did a spike to see if marking the PK of the target model as the FK for a hasOne relation works and it has proven successful, so I'm going to continue that route and merge it back to the original PR. There's lots of discussion that you can look at in #1956. I was away from LoopBack work last week, but will be working on the hasOne PRs this week. Feel free to review them and leave your feedback 👍.

[dhmlau]

Q1 is done.