[Release] 🚀 4.0 GA 🚀

[bajtos]

This is a high-level issue keeping track of the upcoming release LoopBack 4.0 GA.

Release Date

LoopBack 4.0 GA was released in October 2018, read more in the Announcement blog post.

We have reset the version number back to 1.0.0 for all LoopBack 4 packages.

For example, instead of [email protected], there are three new packages in the @loopback scope:

• @loopback/[email protected].
• @loopback/[email protected].
• @loopback/[email protected].

Overview

LB4 positioning: a next-gen framework for building API servers.
Primary target audience: developers building modern/open APIs exposing existing (legacy) assets. LoopBack's role is to serve as a glue tier.

Stories to drive the functional scope

A front page of a major retail e-shop. Components:

• user profile (from a database)
• shopping cart (stored in a distributed in-memory cache, e.g. Redis)
• product recommendation (fetched from a SOAP/REST service connected to AI)
• order history (data related to user profile, stored in a database).

A user sign-up (registration), where the client app is submitting new model data.

Scope

See the current list of stories we are considering as a candidate for GA release here:
https://github.com/strongloop/loopback-next/labels/Core-GA

LB4 website #817

• Add static site generator adding a static site generator to reuse header and footer strongloop/v4.loopback.io#14
• Add resources page LB4 web site: Resources page strongloop/v4.loopback.io#26
• Add contribute page LB4 web site: Add contribute page strongloop/v4.loopback.io#27

Model Relations #1421

Support "Order history" component in the front-page story.

• BelongsTo [Relation] Support BelongsTo relation #1361
• HasOne [Relation] Supports HasOne relation #1422

Stretch goals:

• CLI tooling [CLI] add lb4 relation command #1359

Integration with REST / SOAP services #1460

Support "product recommendation" component in the front-page story

• Boot - load services automatically from files Sugar API for registering services + automated registration via boot #1439

Stretch goals:

• CLI tooling - CLI: a command to create a new service #1312
• Strongly typed integration - spike [Spike] Strongly typed integration - compile-time check #1070

Validation and coercion at REST layer #1456

Support "new user sign up" story. Interesting cases: the provided email address must be unique and also a valid email per RFC spec.

• Validate and coerce most OpenAPI parameter/data types
• Validate (and coerce?) complex request bodies as described by JSON Schema subset supported by OpenAPI.

Extension infrastructure #1034

For GA, do a spike story to confirm feasibility of each of the following extension use cases:

• Custom booters - [Spike] Allow extensions to contribute custom booters #1461
• Custom authorization strategies/providers - [Spike] Allow extensions to contribute custom authorization providers and strategies #1462
• Custom validators and serializers/deserializers for REST layer - Spike: allow extensions to contribute custom validators and serializers/deserializers for REST layer #1463
• How to apply environment-specific operational configuration (e.g. configure datasources from environment variables, use a faster but less-secure hashing algorithm in dev/test) - [Spike] Allow extensions to contribute custom convention for environment-specific operational configuration #1464

Benchmarking and performance

The work depends on validations, but it should be done early to give us room to make improvements (low-hanging fruits).

• Performance benchmark [Spike] Performance benchmark  #534

Cloud Native Experience #1459

Utilize external tooling and document the steps to enable cloud deployment.

• IBM Cloud [Spike] Deploy LB4 applications to IBM Cloud #1446

Stretch goals:

• Spike: Integrate IBM Cloud Yeoman generator with LoopBack [Spike] Integrate IBM Cloud Yeoman generator with LoopBack #1455

Usability Improvements

Scope to be defined on an on-going basis using existing GitHub issues pushed out of DP2/DP3 releases.

e-commerce demo scenario #1476

• user profile (from a database) Demo scenario: User Profile Component #1480
• product recommendation (fetched from a SOAP/REST service connected to AI) Demo scenario: Product Recommendation component #1482
• order history (data related to user profile, stored in a database). Demo scenario: order history component #1483
• shopping cart (stored in a distributed in-memory cache, e.g. Redis) Demo scenario: Shopping Cart Component #1481 (stretch goal)

Nice to have (stretch goals)

• Built-in API explorer [API Explorer] Self-hosted API Explorer #559
• KeyValue repository [Epic] KeyValue repository #1447 - Support "shopping cart" component from the front page story.

Out of scope

• More relations [EPIC] More Relations (post-GA) #1450
• More benchmarking [EPIC] Benchmarking and performance (post-GA) #1451
• Futher REST layer improvements [EPIC] REST layer improvements (post-GA) #1452
• Production deployment/logging/monitoring Production deployment/logging/monitoring #1054
• GraphQL support
• Plain JavaScript experience Plain JavaScript experience #560
• Lifecycle (start/stop) Lifecycle (start/stop) #1039 (We need start/stop for database connections and other connectors that hold resources.)
• Authentication.
  The reference Passport-based implementation shown in @loopback/authentication is a proof that LB4 design is flexible enough to allow app developers to build their own authentication plugin/extension. Post-GA: make @loopback/authentication the recommended module for dealing with authentication.
• Authorization Extension: Add Authorization component #538
• Extension points and interfaces for authentication and authorization Authentication and Authorization extension points #1035
• Extension: Logging Extension: Logging #1037
• Migration from LB3 Migration guide between LB3 to LB4 [MVP] #453

[dhmlau]

@bajtos @raymondfeng , I'm thinking we might need some migration story for GA. It may not need to be complete, but at least some guidelines on what existing LB3 users can do with their LB3 apps. It also helps the adoption of LB4. What do you think?

[bajtos]

I agree a migration story from LB3 is important.

On the other hand, 4.0 GA will have significantly less features than 3.x provides, I am not sure how many LB3 users will be able to upgrade their applications to 4.0 right after it goes GA. To me, it makes sense to initially treat LB 4.0 as a tool for building new applications and deal with migration from LB 3.x only few months later, when we get closer to functional parity.

[ataft]

Our company uses Loopback 3 and truly hope that you make it a priority to support your existing customers with their migrations to v4. We're excited about the improvements in v4, but also see that general support/development for v3 is near non-existent, so worry about how long it's going to take to get to parity. As I'm sure many others in the v3 community are, we're waiting for or holding off on bug fixes and improvements with the understanding that many things will be addressed in v4. Please make us a priority.

[dhmlau]

@ataft, thanks for your (and your company's) support on LoopBack 3 and happy to hear the excitement on LoopBack 4. While getting our heads down on LB4, we're trying our very best to triage and fix the LB3 issues as soon as possible. I apologize if issues take longer than expected before one of our maintainers get to it. Please feel free to let us know if there are particular issues you want us to look at first by commenting in the ticket.

[jdegger]

Estimated release date is October 2018. Is this estimation realistic? We are planning some new projects and are wondering if we can use LB4 rather than 3.

Looking forward to it!

[virkt25]

@jdegger Yes! The team is aiming for a stable V4 release that is production ready for October -- of course depends on progress. I'd encourage you to start learning it, using it and sharing any feedback with us.

[ptesar-xyndata]

Are there any breaking changes between GA and current release? Should I start with adopting for a PoC Webproject of mine? Thx!

[virkt25]

Are there any breaking changes between GA and current release?

@PatrikTes I'd say start adopting the current release to prepare for GA right around the corner and if you encounter any issues, bugs let us know. I expect minimal (if any) breaking changes between now and GA as the focus is on fixing bugs and improving the developer experience by adding features to the CLI.

[elv1s]

will all the relationships from LB3 be in LB4?

Thanks!

[mightytyphoon]

Hi,

I'm very excited to use loopback 4.0 in production for an all new project that should be released at the end of the year and I also wanted to thank you for your awesome work. Thanks for making a framework that permits big projects with continuously taking care of it through the years so teams can use it to develop awesome stuff with the use of nodejs.

I already started making the API with the last dev preview version, I wouldn't mind if some changes occur between the preview and to production release.

But I wanted to know if after the launch of production release, all updates will be backward compatible ?

I think yes but I just ask for a confirmation and wanted to use this message to also thanks the team.

Regards.

[raymondfeng]

@mightytyphoon Thank you for the encouragement. LoopBack won't go long without a great community!

Speaking for backward compatibility, we'll follow semantic versioning to ensure existing apps won't be broken as we roll out future releases. The team will try hard to keep the stability of our public APIs. In some cases, there will be breaking changes we have to make but such things will be released as a new major.

[dhmlau]

will all the relationships from LB3 be in LB4?

@elv1s, is there a particular model relations you're looking for?
For the GA release, we're planning to have BelongsTo #1361 (currently it's working in progress). We have the intention to add hasOne, hasManayThrough and hasAndBelongsTo (see #1421 for details), however, it's not in our next 90-day roadmap after GA. If you have any particular requirements, please let us know!

[elv1s]

Thanks @dhmlau; We have a requirement for hasOne in addition to hasMany and belongsTo

[alfonsocj]

Hello! We are starting a project with Loopback soon. I really want to use Loopback 4, is still October the target date for GA? I wouldn't want to use Developer Preview 3 in production since we have thousands of users that will rely on this service.

[dhmlau]

@alfonsocj , thanks for your interest and support for LoopBack 4. Yes, we're still targetting for October GA date. Since we're very close to the finish line, I'd encourage you to start playing around with LB4 now.

[samarpanB]

Hello Loopback Team ! First of all great job you guys for LB4. It feels awesome to see Typescript at the core of it. Definitely the way forward. Really love TS.
We are also starting a new project and we are evaluating LB4 as framework for the same. Since, we are thinking about having Angular 6 at front end as well, so TS both at front and back end would work well for the team. We can then concentrate on one language only. But during our evaluation process, we are having some open questions which we need answers for. Some of those which we could not find an answer elsewhere in your forums and GH issues, I am listing them here. We'll be glad if you can answer them for us.

1. Will October GA release be production ready ?
2. Is there any APM tool readily available and fully supported to be used with LB4 out of the box ? Similar to new-relic, etc.
3. Oauth 2 support in-built within framework or not ? If yes, any documentation link for the same ? If no, how do we do Oauth with new LB4 ?
4. Elastic Search supported as datasource in LB 4 or not ? I can see its listed when generating data sources using cli but is it really supported or its just a stub in this version ?
5. Is there any in-built ACL support available ?
6. lb4 repository. This cli command seems to be not working. Is this completed or we should create repository classes manually ? Fixed in 0.28.0 version of cli.

We have never used earlier versions of Loopback. So please pardon my nescience.

[marioestradarosa]

6. lb4 repository. This cli command seems to be not working. Is this completed or we should create repository classes manually ?

@samarpanB, We had two issues with lb4 repository so far, and they are already fixed. However the fixes are present in lb4 cli version 0.28.0.

The issues reported and fixed were:

• It depends on typescript as a dependency
• couldn't identified datasource names such as MyDS , this was creating the file my-ds.datasource.ts

If you experience something not related to the two issues above, please open an issue so we can check on it and fix it as soon as possible.

[samarpanB]

Thanks @marioestradarosa for the update. Yes we were facing the issue related to typescript dependency. Glad to hear that its resolved. We'll wait for 0.28.0 version to evaluate this further.

[bajtos]

@samarpanB

Will October GA release be production ready ?

Yes, although certain things (e.g. listening on the port number provided by the environment variable PORT) may require manual configuration for now.

Is there any APM tool readily available and fully supported to be used with LB4 out of the box ? Similar to new-relic, etc.

We don't have any immediate plans to integrate with specific APM tooling. So far, LoopBack was not making any assumptions about the APM tooling used the applications and I believe it works great with any Node.js APM tooling.

If you are looking for a solution backed by IBM, then please check out appmetrics.

Oauth 2 support in-built within framework or not ? If yes, any documentation link for the same ? If no, how do we do Oauth with new LB4 ?

Oauth2 is on our roadmap but it's out of scope of 4.0 GA. @raymondfeng can you help please?

Elastic Search supported as datasource in LB 4 or not ? I can see its listed when generating data sources using cli but is it really supported or its just a stub in this version ?

The Elastic Search connector is maintained by LoopBack community. I don't know how stable it is, but considering the number of contributors, I would expect it to work reasonably well - at least for basic use cases. YMMV.

Is there any in-built ACL support available ?

Not yet. We haven't figured out the authorization story yet, but it's on our short-term roadmap to make it easy to add different authorization rules to LB4 apps.

[dhmlau]

Closing this ticket as done! 🎉
See announcement blog: https://strongloop.com/strongblog/loopback-4-ga

[larsm11]

The below announcement is still showing on the LB4 home page, I wonder if that isn't a mistake.

"Important: LoopBack 4 is the next step in the evolution of LoopBack. It is still in early development and is not yet released"

[dhmlau]

@larsm11 , thanks for bringing it up. I've updated the docs in PR #1859. It now needs to be refreshed on loopback.io.

[tioback]

@dhmlau it seems #1859 was accepted before 4.0 GA tag was released.

[dhmlau]

@tioback , thanks for checking. It's possible that the PR had merged before that. For the docs content in loopback-next repo, we need to release @loopback/docs in order to be sync to loopback.io.

[tioback]

@dhmlau just to be sure: was v4 released or not?
If it was, would you or someone else be able to create and publish tag?
If it wasn't, should this ticket be reopened?

[bajtos]

@tioback sorry for the confusion. v4 was released, but since we have changed package names as part of the rewrite, the new packages use 1.x.y versions. For example, @loopback/core is at 1.0.1 right now.

Could you suggest where should we capture this information to save future readers from this confusion?

[tioback]

Hi, @bajtos .
No need for apologies, let's settle for a tag 🤣

Perhaps the announcement note about v4 release, a new column right at the LTS table might be a good place.

Jokes aside, I do believe a tag at the master branch named something like "loopback-4.0.0-GA" at the commit which released v4 would be of great help.

[bajtos]

@tioback thanks for the suggestion. I'll take a look at improving the announcement blog post. Until that happens, I have edited the issue description at the top to make it clear that LoopBack 4.0 GA was released and package versions were reset to 1.0.0. I hope it will help new people coming across this issue in the future.

[bajtos]

I am reluctant to use a custom tag like loopback-4.0.0-GA because I don't really what would be the use of it. I mean developers should install the latest version published to npmjs, not the version tagged as GA.

[tioback]

Well, tagging isn't only for running, but also for cloning, or just knowing exactly what commit is the release related to.

I agree with you that people should install the latest version when developing, however, for production scenarios, it is a good practice to use a fixed tag or version.

[bajtos]

FWIW, the announcement blog post was updated, see https://strongloop.com/strongblog/loopback-4-ga#new-module-names

Well, tagging isn't only for running, but also for cloning, or just knowing exactly what commit is the release related to.

I see. Well, we do have a git tag for each release of each of our module, see https://github.com/strongloop/loopback-next/releases.

I agree with you that people should install the latest version when developing, however, for production scenarios, it is a good practice to use a fixed tag or version.

AFAIK, this is solved by npm shrinkwrap. IT does not depend on specific git tags and locks versions for all project dependencies, not only LoopBack packages.

Let's end the discussion here at this point please. If there is anything else to discuss, then please open new GitHub issues.