We’re one month into the new year! While the team had some time off extending into January, we still managed to work and spike on authentication, migration from LB3, user adoption, extensibility, and documentation. Read more to find out how it all unfolded.
Last month we implemented the strategy resolver, JWT strategy class and authentication action and created the diagram that depicts their dependency relations. Based on those efforts, in January we enriched the
loopback4-example-shopping repository with a working JWT authentication system, and added two endpoints for model
User to make use of it:
POST /Users/loginverify a user’s credentials and return a valid JWT access token
GET /Users/medisplay the logged in user of the application
The following picture describes how the authentication mechanism works:
This month our discussion focused on dividing the responsibilities among controller, repository and services/utilities.
The login related logic should be extracted into a service which could be shared among different clients, like REST, gRPC and WebSocket. Those logic include taking in credentials, verifying users, generating and decoding access token. The login service receives User’s repository via DI. As the first implementation, we simply keep them as utils. They will be refactored into service in story Refactor authentication util functions into a service
The controller function should extract credentials like email, username and password from the request. And calls the service to perform login. The service is injected via DI.
We also discovered there are three extension points that are needed in order to make LoopBack’s authentication system more flexible. We need extension points such as:
- plugin Passport based strategies leveraging the existing auth action in
- plugin non-passport based strategies like the JWT strategy created by us.
- a more flexible user profile type that allow people return custom properties.
PR https://github.com/strongloop/loopback-next/pull/2249 illustrates extension point/extension pattern is in progress. It provides a standard to make extension point that the 3 above stories could follow.
A more detailed tutorial will be created after finishing the story Refactor authentication util functions into a service.
You can checkout the hack branch of
Also, in PR #795, Nora improved the UX for users on
loopback.io by setting up redirects for the current LoopBack 4 website and LoopBack 3 in Active LTS, akin to how Node.js has the split for the different version downloads in their main landing page.
We continue to refine our extensibility story as we build more extensions.
BindingFilterto match multiple bindings using a function.
- Refactored code to use it for Context APIs such as
To make it easy to implement the extension point/extension pattern, we’re building up new features for
@loopback/context. There are number of PRs under review.
- Add support for
- Allow observers to register with the context chain and respond to come and go of bindings of interest
- Add support for
- PR#2122 (depends on #2291)
ContextViewto dynamically resolve values of matching bindings
@inject.viewto support dependency injection of multiple bound values
@inject.getterto support multiple bound values
- Add an example package to illustrate how to implement extension point/extension pattern using LoopBack 4’s IoC and DI container
- Propose new APIs for
Contextto configure bindings
@inject.configto simplify injection of configuration
- Propose new APIs for
You are welcome to join our discussions in these pull requests. Please be aware that such PRs can be changed or abandoned during the review process.
We’re always striving to have better documentation for our users. In PR#2214, Nora added much needed descriptions to our relation decorators page with clear examples on how they are applied. Moreover, Dominique wrote an excellent guide on how to publish a LoopBack 4 application to Kubernetes on IBM Cloud in PR#2160. Check it out here.
LoopBack v3 compatibility layer
In January, Miroslav implemented a proof of concept showing a compatibility layer that would allow application developers to take their model files (
.js) from an existing LB3 project and drop them mostly as-is to a LB4 application.
The idea is to simplify the migration path from LB3 to LB4 by allowing developers to update their existing applications from LB3 to LB4 runtime (and dependencies) without having to rework their source code to the new programming model yet.
With the proposed compatibility layer, LB3 models are “upgraded” to use:
loopback-datasource-jugglerversion 4.x (instead of 3.x)
@loopback/restfor REST APIs (instead of
- OpenAPI v3 (instead of Swagger a.k.a. OpenAPI v2)
@loopback/rest-explorerfor API Explorer (instead of
The migrated models will run fully on LB4 runtime and thus enjoy longer LTS.
If you have an LB3 application and considering upgrading to LB4, then please join the discussion in PR#2274. Your feedback is very important to us!
While waiting for more feedback from our users, Miroslav reviewed early input and started to look into ways to mount an entire LB3 application inside an LB4 project. While such solution still depends on LB3 runtime that will eventually go out of support, it will provide almost 100% backwards compatibility and require very little code changes. Let us know if this option would be useful for your project and leave a comment in [PR#2318]strongloop/loopback-next#2318).
Community Engagement Events
Toronto LoopBack Meetup
The LoopBack team hosted a meetup in downtown Toronto on February 5th, 2019. We taught users all about LoopBack 4 and demonstrated the capabilities and integrations of the framework. We worked hard to prepare presentations and demos for the meetup during this month. If you are in the Toronto area and are interested in future meetups, check out the Toronto Cloud Integration Meetup Group and make sure to sign up!
February is an event-filled month. Besides the meetup in Toronto, there will be LoopBack coverage at Code @ Think in Node.js Master Class and as one of the Quick Labs. Raymond will be presenting at DeveloperWeek on Feb 21 on the topic – Speed and Scale: Building APIs with Node.js, TypeScript and LoopBack.
Twitter is a great way to stay in the loop with StrongLoop and LoopBack news. The best way to learn about events we are part of is generally https://strongloop.com/events/.
Welcome New Core Maintainer
We’d like to introduce our new LoopBack development team member Dominique at our Markham lab. Dominique brings lots of experience and knowledge from working in Message Broker and App Connect development team in the past. He has already given us a step-by-step tutorial on how to deploy a LoopBack 4 application to Kubernetes in IBM Cloud here. Welcome, Dominique!
Call to Action
LoopBack’s future success depends on you. We appreciate your continuous support and engagement to make LoopBack even better and meaningful for your API creation experience. Please join us and help the project by:
- Reporting issues.
- Contributing code and documentation.
- Opening a pull request on one of our “good first issues”.
- Joining our user group.