Photo by S O C I A L . C U T on Unsplash

Since then, the framework has gained stability and has gained users substantially. We also see more contributions from the community not only to the core framework, but also building extensions. Thank you for all your contributions to LoopBack and the 160+ extensions published on npmjs.com!

To continue moving towards an open governace model, it's exciting to see LoopBack joined the OpenJS foundation as the incubating project in 2021 and graduated to at-large project the following year.

Lastly, don't forget that HacktoberFest is on this month. No matter you're a new developer to LoopBack or seasoned contributors, your contributions are always welcomed!

As part of the planning for LoopBack moving to OpenJS Foundation, there have been discussions around finding a new home for the blog, parting from the strongloop.com web site. A few alternatives had brought up, such as having the blog posts as part of the loopback.io repo, using a third party blog site and creating a blog site in a separate repo.

Coming Up With a Plan​

Putting the blog posts in the loopback.io repo is a natural progression, since all the documentation and text-based content will be in the same repo. The concern is that is Jekyll-based. Although it worked fine and integrated well with GitHub Pages, many of the maintainers were not well-versed in the world of Ruby. This was compounded by shell scripts that pulled data from other Git Repositories and modified the site as part of the build process. Hence, a lot of time was spent trying to understand how the website was put together and figuring out the best way to tweak it to integrate the new blog.

The "Strong Blog" was also written with Jekyll and hosted on GitHub Pages. Hence lifting and shifting was a real possibility that we contemplated. However, the slow build times and the maintainers' unfamiliarity with Ruby and Jekyll meant that we realised that the website's current stack wasn't worth keeping around in the long run. At the same time, performing a full migration of the website, documentation, and blog in one go was too daunting of a task for the maintainers who were already working on the project on their own time.

The idea of using a third-party service such as Medium was also considered. However utlimately, the lack of control over the interface, the inability to place it in the same domain name as the main website and documentation, and the frustration that stem from a reader being forced to use a third-party service meant that it was quickly off the table.

As a result, we decided to come to a compromise.

Picking A Blogging Stack​

After some deliberation we decided to create a hybrid stack which left the website and documentation with Jekyll, and use Docosaurus 2 as the new blogging platform. We found Docusaurus to be a good fit as it is a Facebook-maintained open source project which was written on top of React. Besides its benefit of speedy build times, this JavaScript-based stack provides more opportunities for extensibility and a reduced barrier for contributing and tweaking. The first-class support for MDX was also a plus as it meant we were able to copy over most of our posts with only a few tweaks, and the ability to generate the blog as build artifacts made it compatible with the Jamstack-eque system of GitHub Pages.

Thanks to the amazing work done by Diana, all of the LoopBack 4 blog posts from 2019 and 2020 were migrated to Docusaurus. With her work, we were able to quickly build and see the new blog coming together with all of the past blog posts populating the blog.

Merging Jekyll and Docusaurus​

When we started building the blog, we hosted it on GitHub Pages in its own Git Repository and served it in its own sub-domain. This allowed us to quickly build and patch any bugs that may have cropped up. However the end-goal was to host it under the same domain as the main website and documentation: https://loopback.io/blog. Hence, we had to create a solution which merged the new blog with the exsitng website codebase.

This solution? A shell script!

Since we already had a precedence for using shell scripts to pull in data from other Git Repositories, I've decided to write one to do the same thing, but this time, specifically for the blog. This script clones the loopbackio/loopback-blog Git Repository, generates the blog's build artifacts, and copies it over to the blog directory of the Jekyll website. There's additional logic in there to make it more fool-proof and less verbose but in essence, that was what it did - Clone, build, and copy. You can also view the source code yourself if you'd like to see how it was done. Over time, we hope to refine this further and make it more reliable, such as using Git Submodules instead of a clean clone on every build.

Future Work​

As it stands, we now have a blog that all of the maintainers can now contribute to. With this change, we now have revived a new way for us, the maintianers, to engage with our community and we hope that the blog posts can complement the existing documentation and community channels such as Slack, GitHub Discussions, and the mailing list.

This is just the first step in modernising our website stack. There's still plenty of work to do, and it's our vision to fully migrate our stack to one powered by the JavaScript ecosystem.

Upcoming Blog Series: Maintainers' Testimonial​

With the launch of our new blog, we're excited to announce an upcoming blog series where the maintainers can share their expriences and journey in adopting LoopBack 4. Through this series, we hope to share with the community the unique perspectives of those who work closely on LoopBack 4, not only as users but as maintainers as well.

Don't miss out on future blog posts by subscribing to our RSS or Atom feeds which contain the full articles.

Hope you had a wonderful Thanksgiving for those who celebrate it! In November, LoopBack team focused on improving the context module and documentation, as well as bug fixes. The Toronto squad participated in the CASCONxEVOKE conference. Instead of a physical booth, we held a virtual one online. We welcomed @nflaig as the new maintainer of loopback-next.

Read more to know about the highlighted improvements:

Context​

• A new phase init() was added to the application life cycle events. It is used when a component need to contribute bindings asynchronously. For example:

  export class MyComponent implements Component, LifeCycleObserver {
    // ...
    async init() {
      // Contribute bindings via `init`
      // This cannot be done via constructor since it's synchronous.
      const val = await readFromConfig();
      this.app.bind('abc').to(val);
      this.status = 'initialized';
      this.initialized = true;
    }
  }
  

  You can check the Component page to learn about its usage.

• toInjectable() was introduced as a shortcut to decorate a common/provider/dynamic-value-factory class and automatically creating binding for them. For example:

  @injectable({scope: BindingScope.SINGLETON})
  class MyController {
    constructor(@inject('my-options') private options: MyOptions) {
      // ...
    }
  }
  
  binding.toInjectable(MyController);
  

  The decorator's usage is well documented on page Binding.

• PR #6701 updated test cases to reflect how the design types of array/undefined/complex properties are retrieved.

• Method injection is allowed for the lifecycle methods in PR #6740. For example:

  class MyObserverWithMethodInjection implements LifeCycleObserver {
    status = 'not-initialized';
    init(@inject('prefix') prefix: string) {
      this.status = `${prefix}:initialized`;
    }
    start(@inject('prefix') prefix: string) {
      this.status = `${prefix}:started`;
    }
    stop(@inject('prefix') prefix: string) {
      this.status = `${prefix}:stopped`;
    }
  }
  

• In some cases, your Express middleware wants to access LoopBack's RequestContext to resolve certain bindings. This can be done via MIDDLEWARE_CONTEXT property of the Express request object, which is set up by LoopBack when the RequestContext is instantiated. For example:

  import {MIDDLEWARE_CONTEXT, RequestContext} from '@loopback/rest';
  function expressHandler(req, res, next) {
    const reqCtx = (req as any)[MIDDLEWARE_CONTEXT];
    // Now you have access to the LoopBack RequestContext
  }
  

Documentation​

• The guide for calling REST APIs and SOAP services were separated to make the steps involved clearer. You can check the overview page Accessing services and its sub-topics Calling SOAP web services and Calling REST APIs for details.

• For troubleshooting, we added steps for creating breakpoints in vscode in the documentation. You can find more details in PR #6743.

REST​

• Matching a URL or hostname against a regular expression that contains an unescaped dot as part of the hostname might match more hostnames than expected. PR #6813 updated the regular expression of hostnames accordingly.

Repository​

• #6755 threw 400 BadRequestError for invalid inclusion relation name by rejecting the request with statusCode as 400.

Examples​

• PR #6598 updated artifacts of the todo-list example to the latest style generated by the LoopBack CLI.

Enriching LoopBack and its Community - You are Invited!​

As mentioned in our recent blog post, your contribution is important to make LoopBack a sustainable open source project.

Here is what you can do:

• Join LoopBack Slack community
• Look for first-contribution-friendly issues
• Give us feedback and join our discussion in our GitHub repo

Let's make LoopBack a better framework together!

In October, we were excited to see an increasing number of community contributions as people joined the Hacktoberfest event. This month we had pretty balanced improvements in each area of the framework, including context, health check, OpenAPI specification and documentations. Keep reading to learn about the recently added features!

We welcomed @mrmodise as the maintainer of loopback4-shopping-example. And we'd like to thank everyone @nflaig, @MattiaPrimavera, @mdbetancourt, @mrmodise, @frbuceta, @HrithikMittal, @simlt, @hectorleiva, @pktippa, @VergilSkye, @kerolloz, @arondn2, @mayank-SFIN571 for your contributions in October!

Here are the highlighted improvements:

Context​

• A set of fine-grained scopes APPLICATION, SERVER and REQUEST has been introduced to allow better scoping of binding resolutions. The limitation of the previous scopes is explained in section choose the right scope, and section resolve a binding value by key and scope within a context hierarchy explains how different scopes determine the binding resolutions.

REST​

• Allowed array query parameter for a single value, like {tags: 'hello'} where parameter tags is a string array. See PR #6542.

• Supported property level configuration for hidden fields, like @property({type: 'string', hidden: true}) password: string. This is the shortcut for specifying the hidden properties in model settings. See PR #6484.

• save() method throwing error due to missing idName is fixed in PR #6640.

• modifySpec() turns to an async function to allow async spec updates. See PR #6655.

Build​

• A force clean rebuild was added to the pre-start script for the LoopBack 4 examples. You can run npm start after removing artifacts without manually cleaning the /dist files. See PR #6588.

• Turned on exit for mocha tests for the created LoopBack applications. See PR #6475.

Extensions​

• Module @loopback/socketio was added to use socket.io to expose controllers as WebSocket friendly endpoints.

• Enable/disable the metrics endpoints in explorer when mounting the metric and health extensions. See PR #6646 and PR #6645.

• Only add MetricsObserver, MetricsPushObserver and expose /metrics endpoints when they are enabled. See PR #6644.

• The health check for applications running in container now returns a more accurate HTTP status code based on the state. For example, checking /health for application in states 'STARTING', 'STOPPING' or 'STOPPED' returns 503. You can find more details in PR #6648.

Documentation Restructure​

• LoopBack 4 targets both API developers and extension developers, while the current website doesn't distinguish them clearly. This month we restructured the sidebar to classify the documentation into two parts: "Building LoopBack Applications" and "Extending LoopBack Framework". You can check https://loopback.io/doc/en/lb4/Customizing-server-configuration.html to view the new layout.

• The instructions for implementing HTTP redirects and mounting an Express router are extracted into a standalone page under "How-to guides". You can check https://loopback.io/doc/en/lb4/Customizing-routes.html to view the content.

• Moved server recipes to how-to guides Customizing-server-configuration. See PR #6663.

Examples​

Two examples were added last month:

• Example webpack was added to demo LoopBack running inside the browser as client-side JavaScript application.

• Example socketio gives a basic implementation of socketio with LoopBack 4.

You can also download the examples by using the lb4 example command.

Enriching LoopBack and its Community - You are Invited!​

As mentioned in our recent blog post, your contribution is important to make LoopBack a sustainable open source project.

Here is what you can do:

• Join LoopBack Slack community
• Look for first-contribution-friendly issues
• Give us feedback and join our discussion in our GitHub repo

Let's make LoopBack a better framework together!

It's been 6 months since we created the Slack channel for LoopBack community. Thanks to your support, over 500 members had joined and new members are joining almost everyday! Let's take a look at the October edition of the “Community Q&A Monthly Digest”, capturing some of the Q&A in this forum.

Question: How to get the raw request in LoopBack 4 in a function without changing the parsing for the entire app?

Answer: It's possible to get the raw request body with x-parser: https://loopback.io/doc/en/lb4/Parsing-requests.html#extend-request-body-parsing. -- Answered by @Rifa Achrinza

Question: Is there any solution for tracking database migration, for example, migrations has been already run and possible rollback of migration?

Answer: I created a module which tracks migrations and executes scripts based on the db version compared to the app version, see https://www.npmjs.com/package/loopback4-migration. --Answered by @nflaig

Ideally, LoopBack generates the DDL for users to review, and then it’s up to the users to run it or not. It's a feature to be implemented, see https://github.com/strongloop/loopback-next/issues/4757. --Answered by @Diana Lau

Question: I want to check whether a specified categoryId exists in a Mongo datasource, how can I do that? For example,

{"categories" : [
    {
        "categoryId" : "e759c15e-3552-4557-aa6b-c1396674c7e6",
        "name" : "test"
    },
    {
        "categoryId" : "e759c15e-3552-4557-aa6b-c1396674c7e5",
        "name" : "test1"
    }
]}

I tried await this.usersRepository.find({'categories.categoryId': 'e759c15e-3552-4557-aa6b-c1396674c7e5'}); but getting an error message below:

> { 'categories.categoryId': string; }' is not assignable to parameter of type 'Filter<Users>'. Object literal may only specify known properties, and ''categories.categoryId'' does not exist in type 'Filter<Users>'

Answer: The object you pass into .find() needs to be a Filter object. Make sure you import { Filter } from '@loopback/repository';, then you can:

const existingCategoryFilter: Filter = {
  //...filter properties in here...
};
let existingCategories = await this.categoryRepository.find(existingCategoryFilter);

-- Answered by @Jackson Hyde

To add on what @Jackson Hyde has mentioned, due to limitations on TypeScript types, nested objects are not included in the typings. Hence, you'll also need to override TypeScript's check by adding // @ts-ignore just before the repository function. -- Answered by @Rifa Achrinza

Question: I want to implement JWT refresh token in LoopBack 4. Can you suggest any good tutorial?

Answer: You can follow this https://loopback.io/doc/en/lb4/JWT-authentication-extension.html. --Answered by @Pratik Jaiswal

Question: I used LoopBack CLI to create a "SHIPPING" model but it tries to do lowercase "Shipping" in the SQL with the quotes. An error occurred in the SQL statement because it is case sensitive with the quotes around it. How can I fix this? I'm on LoopBack 4 and using the loopback-connector-ibmi.

Answer: Did u try to give the name in your model?

@model({name: 'member_membership'})
export class MemberMembership extends Entity {
    //...
}

So member_membership is the table in the database. -- Answered by @Mohammed

The name property customizes the model name, which is default to the class name if not provided. The model name is then used as the default for table name unless you further customize it for specific databases. -- Answered by @Raymond Feng

Question: I have a CORS issue with passport-login example when trying to establish connection with Google using Angular Frontend. I keep getting CORS error:

Access to XMLHttpRequest at 'https://accounts.google.com/o/oauth2/v2/auth?...' (redirected from 'http://localhost:3000/api/auth/thirdparty/google') from origin 'http://localhost:4200' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource."

But the application is working fine with jade.

Answer: In your login component you could do something like:

OAUTH2_LINK_GOOGLE = this.api_url+'/api/auth/thirdparty/google?redirect_uri=' + this.redir_url
  onGoogleSignIn() {
    window.location.href = this.OAUTH2_LINK_GOOGLE;
  }

Bind the Google link to the above in the HTML code.

-- Answered by @marg330

Enriching LoopBack and its Community - You are Invited!​

As mentioned in our recent blog post, your contribution is important to make LoopBack a sustainable open source project.

Here is what you can do:

• Join LoopBack Slack community
• Look for first-contribution-friendly issues
• Give us feedback and join our discussion in our GitHub repo

Let's make LoopBack a better framework together!

Fall is the season of the harvest. We're glad to see the good progress that we've made in the past 3 months, together with the contributions from the community. In September, there is record high percentage (25.6%) of the merged PRs which are coming from the community. Thank you all!

If you haven't heard of Hacktoberfest happening this month, check out the details in our previous blog on Hacktoberfest. There's still time to join. For those who participated, we appreciated your contributions.

Let's take a look some of the highlights in the last quarter by you and the LoopBack team.

Integrate with TypeORM, TypeGraphQL and MessagePack​

One of our strategies to add value to LoopBack is to leverage third-party libraries and integrate with them. We created the following extensions:

• @loopback/typeorm: enables TypeORM support in LoopBack
• @loopback/graphql: integrates with TypeGraphQL for creating GraphQL API https://loopback.io/doc/en/lb4/GraphQL.html
• @loopback/rest-msgpack: adds support to allow receive MessagePack requests and transparently convert it to a regular JavaScript object. It provides a BodyParser implementation and a component to register it.

Reorganize and Enhance Documentation​

To better organize our content and easier for navigation/discovery, we reorganized our content based on four quadrants: tutorials, how-to guides, concepts and reference guides. To find out more how our documentation is organized, see this documentation page.

Besides the ongoing refactoring work, we enriched the content and clarified on some of the topics that are frequently asked by you. For example, we:

• cleaned up the documentation about LoopBack extension so that your extension creation experience would be easier and smoother. We'll continue to make some more improvement in this area as well.
• enhanced the content for authentication and authorization to include basic concepts, usage and examples.
• added a section on accessing multiple models inside a transaction

Other Key Feature Highlights​

There were many features, fixes and enhancements in the past few months, and here are some highlights:

• completed the HasManyThrough relation
• improved REST experience by adding a middleware based sequence
• added support for applying multiple authentication strategies to one endpoint
• implemented the refresh token service in the @loopback/authentication-jwt extension
• added the support of OpenAPI parameter AJV validation on simple types and AJV formats for OpenAPI spec data type formats.

Encourage Community Contributions​

In a recent blog post, we shared our views on encouraging more community contributions to match with our growing user community. The switch to Developer Certificate of Origin (DCO) as the contribution method is a change we made to make your contribution process easier. We also created a community extension documentation page to showcase LoopBack extensions built by the community.

In addition, we are pleased to have @nabdelgadir and @madaky to be one of our community maintainers. We appreciate the great work you’ve done and welcome to the team.

Previous Milestone Blogs​

There are many more accomplishments that cannot be captured in this blog, make sure you check out our previously published monthly milestone blog posts in Q3 for more details:

• July summary
• August summary
• Sept summary

Enriching LoopBack and its Community - You are Invited!​

Your contribution is important to make LoopBack a sustainable open source project.

Here is what you can do:

• Join LoopBack Slack community
• Look for first-contribution-friendly issues
• Give us feedback and join our discussion in our GitHub repo
• Limited time only: Join the Hacktoberfest in the month of October

Let's make LoopBack a better framework together!

LoopBack 3 is approaching its end-of-life at the end of the year for community support. For LoopBack 3 users, we hope the migration guide helps you migrate your applications to version 4.

At the same time, we understand you might still be using LoopBack 3 and/or in the process of migrating to LoopBack 4. For the next few months after the EOL date, we'll try to support the community in the following ways:

• Helping the community to migrate: we will continue to help with questions on GitHub and Slack, but it will be on a best-effort basis.
• Security vulnerabilities: Critical security fixes will be applied as needed by IBM API Connect.
• New features: No features will be accepted.
• Bugs: We are not going to actively fix any bugs reported by the community users. For critical bugs, maintainers will review and assess the risks of community-submitted PRs. If you’re planning to submit a fix, it’s the best to open a GitHub issue to discuss with the maintainers before proceeding.

Please note that the December 2020 end-of-life date is applicable to community support. If you are using LoopBack as part of the IBM API Connect v5 or v2018 product, check with the product announcement for its end-of-support schedule.

What Should I Do If I'm Still Using LoopBack 3?​

If you already have LoopBack 3 applications running in production, it is highly recommended for you to review the Understanding the differences between LoopBack 3 and LoopBack 4 page as mentioned in one of our older blog posts. There is also the migration guide helping you to migrate your LoopBack 3 applications incrementally.

What If I Cannot Migrate to LoopBack 4 Any Time Soon?​

Your LoopBack 3 applications will continue to work even after LoopBack 3 reaches end of life. There will be very minimal, if any, changes going into the codebase. In the case of addressing security vulnerabilities, you might need to fork the corresponding GitHub repos and apply security fixes. See this blog for the list of Node.js packages reaching end-of-life along with loopback repo.

Enriching LoopBack and its Community - You are Invited!​

Your contribution is important to make LoopBack a sustainable open source project. Here is what you can do:

• Join LoopBack Slack community
• Look for first-contribution-friendly issues
• Give us feedback and join our discussion in our GitHub repo

Let's make LoopBack a better framework together!

We bring another month of new features, fixes, and improvements in documentation and developer experience in LoopBack. Make sure to update your compatible projects with lb4 update if you want to update the underlying libraries to their latest versions.

Also, as part of our long-term effort to encourage more community contributions, we are participating in this year’s Hacktoberfest. You can read more about the event and participation details at our Hacktoberfest blogpost.

Documentation Enhancements​

There has been a continuous effort to improve our documentation. Below are some highlights for this month:

• A new documentation page, Accessing HTTP request and response objects, was added explaining the various ways and places to access the request and response objects.
• We are working on a series of troubleshooting guides for LoopBack. This month we completed the basic guide and Debugging tests with Mocha. A few more areas that can be added to the guide.
• We added an example app demonstrating LoopBack 4's context binding resolution and dependency injection within a context hierarchy.

New Experimental Features​

• We have created a GraphQL extension that provides integration with GraphQL using type-graphql. Check out the GraphQL example app for a sample app.
• We added support for parsing MessagePack bodies. For usage, refer to the documentation.

Investigation on Better Handling of ObjectID in MongoDB​

We spent a good amount of time to improve the experience of using ObjectID with LoopBack. We have identified the direction we want to take and the tasks to work on. You can learn more about the spike in issue 3456.

Fixes and Improvements​

• added .onStart() and .onStop() methods of the Application, so that they can be used to register observers as plain functions for the start and stop life-cycle events.
• enhanced the lb4 update command to be runnable against any projects that use @loopback/* dependencies in dependencies or devDependencies, or peerDependencies; not just LoopBack 4 projects.
• included the application build when running migrate and openapi-spec scripts.
• added @injectable, so that @injectable can be used instead of @bind, which is in tune with other frameworks using Dependency Injection. @bind is not removed from the framework, so apps using @bind will not be affected.
• made the keepAliveTimeout, headersTimeout, maxConnections, maxHeadersCount, and timeout properties of the underlying HTTP server instance configurable by specifying them in the application config object.
• updated the generated application directory name during application scaffolding when application names involve numbers
• added the ability to boot dynamic value provider classes and classes with @inject.
• removed the extension- prefix from the affected extensions for their names to be consistent with other extension modules.
• improved the overall experience of graphql configuration and subscriptions in LoopBack.
• added the support of OpenAPI parameter AJV validation on simple types and AJV formats for OpenAPI spec data type formats.
• updated the REST middleware so that it can now cached by the use of singleton binding scope.
• added Twitter example in the Passport login example app.

Community Contributions​

Shout out to Rifa Achrinza for explaining the differences between weak and strong relations in PR 6404, MessagePack PR, and his numerous other PRs.

Opening issues are community contributions too, so thanks to all those who help LoopBack become better by reporting bugs and usability issue. We try to address popular issues with higher priority, so continue to let us know the problems you face on GitHub or Slack.

Enriching LoopBack and its Community - You are Invited!​

As mentioned in our recent blog post, your contribution is important to make LoopBack a sustainable open source project.

Here is what you can do:

• Join LoopBack Slack community
• Look for first-contribution-friendly issues
• Give us feedback and join our discussion in our GitHub repo

Let's make LoopBack a better framework together!

As part of our long-term effort to encourange more community contributions, LoopBack is going to participate in this year's Hacktoberfest.

What is Hacktoberfest?​

Hacktoberfest is an annual event encouraging participation in the open source community, open to everyone. Whether you’re new to development, a student, or a long-time contributor, you can help drive the growth of open source and make positive impact on an ever-growing community. All backgrounds and skills levels are encouraged to complete the challenge.

You can learn more about Hacktoberfest values at https://hacktoberfest.digitalocean.com/details#values.

Participants completing the challenge (contributing at least 4 valid pull requests) will earn a limited edition T-shirt.

Please note that any prizes are subject to conditions set by Hacktoberfest. IBM and the LoopBack team are not involved and not responsible in any way.

How to participate​

Joining the effort is simple. Just pick any problem that is itching you and send a pull request to fix it. You can also choose one of LoopBack's issues labelled as Hacktoberfest or good first issue if you need inspiration.

Make sure to familiarize yourself with Hacktoberfest's Participation rules and Quality standards; and also LoopBack's Contributing guide.

Are you new to open source? No problem, we have you covered! Check out Hacktoberfest's Beginners guides and LoopBack's guide on submitting a pull request to LoopBack 4.

For the entire month of October, LoopBack's maintainers team will be giving extra priority to pull request reviews and helping new contributors along their journey to the first accepted contribution.

Focus areas​

We are primarily looking for quick wins with long term impact: small enhancements improving your day-to-day experience while using LoopBack.

As you may know, we have introduced a new documentation system in June to better organize the content and make it easier to find the information you need (see New Documentation Structure and Alignment Along Abstraction Levels). The reorganization is still in progress and we would love to get some help. In particular, extracting recipes from "Concepts" explanations into proper "How-to guides" is an easy way how to quickly score valuable pull requests. See the GitHub issue loopback-next#5783 for the list of docs pages to rework.

Having said that, all improvements are welcome!

Closing thoughts​

We are looking forward to receive and eventually land your pull requests. Let's make LoopBack a better framework together!

Welcome back to the September edition of the "Community Q&A Monthly Digest", in which we are curating some of the Q&A that we think it might be helpful to you. Thank you for posting your questions and helping your fellow LoopBack users.

The LoopBack Slack community is a platform where LoopBack users are helping each other out. If you haven't joined already, sign up today!

Let's take a look at some of the questions and answers from the community.

Question: Is it possible to use auto-generate timestamp property in a model?

Answer: To set the property to the current datetime upon Model Create, you can:

@property({
type: 'date',
defaultFn: 'now',
})
timestamp?: string;

Question: Does LoopBack has any built-in cache? Or should we implement that to make response even faster?

Answer: We currently don’t but there are some example implementations for your reference:

• caching interceptor
• caching service

Question: I want to perform schema migration but the order of tables is important beacause there are some relation and foreign key between them. How can I set the order of tables to be migrated?

Answer: Within migrate.ts, app.migrateSchema accepts a model array. So it can be updated as such:

await app.migrateSchema(Object.assign(<SchemaMigrationOptions>{
models: [/* Add model names here */]
}, existingSchema));

Like with any auto-migration, please do take a backup of the database before running the migration.

Question: I wanted to implement an API like the file-transfer example on the docs but with more endpoints with different storage directories. How is that possible?

Answer: You can have different endpoints backed by different methods using post /<url> decoration as you see at https://github.com/strongloop/loopback-next/blob/master/examples/file-transfer/src/controllers/file-upload.controller.ts#L28. If you want to calculate the file path per request, you can instantiate a new upload service instance instead of using the injected one.

Questions: I work with LoopBack in a k8 cluster, when i try to implement JWT authentication, all users get the same token, and the data in that token is not equal to that user. Is there any way to fix it besides saving the token in a database?

Answer: Typically JWT tokens are generated using a combination of a secret and some sort of UUID of the user. When they successfully authenticate, a token is generated and returned. When you need to verify the token, you decode it using the secret, giving you the UUID of the user. This means that you don’t actually have to save a token at all. Here’s how we are generating tokens for our users.

const userInfoForToken = {
id: userProfile.id,
name: userProfile.name,
roles: userProfile.roles,
};
// Generate a JSON Web Token
let token: string;
try {
token = await signAsync(userInfoForToken, this.jwtSecret, {
expiresIn: Number(this.jwtExpiresIn),
});
} catch (error) {
throw new HttpErrors.Unauthorized(`Error encoding token : ${error}`);
}

In this context, signAsync is a promisify’d version of jsonwebtoken.sign().

Question: I want to use the LoopBack app cli-command programmatically. Is this possible?

Answer: You can try to require('@loopback/cli/lib/cli'). See https://github.com/strongloop/loopback-next/blob/master/packages/cli/lib/cli.js. cli.js has logic to create yeoman env and register generators.

Enriching LoopBack and its Community - You are Invited!​

As mentioned in our recent blog post, your contribution is important to make LoopBack a sustainable open source project.

Here is what you can do:

• Join LoopBack Slack community
• Look for first-contribution-friendly issues
• Give us feedback and join our discussion in our GitHub repo

Let's make LoopBack a better framework together!

Our focus in August is the documentation restructure. The layout of several main sections are reorganized for easier navigation. Another significant improvement is about the request handling. More flexible approaches of adding LoopBack style middleware and express middleware are introduced in @loopback/rest.

We would like to appreciate Agnes Lin's great contributions during her internship. There has been so much fun and pleasure working with her! She will be continue helping us part time. Good luck with your school.

Keep reading to learn about the improved documentation and recently added features!

Documentation Enhancements​

Reorganizing the Concepts List​

The fundamental concepts were listed in section "Behind the Scene" sorted by the publish date. To have a concise name and a more organized layout for users to search, we renamed the section to be "Concepts" and restructured the documentations into the following sub-sections:

• Crafting LoopBack 4
• Core
• REST APIs
• Data Access

You can visit the more organized contents in https://loopback.io/doc/en/lb4/Concepts.html.

Reorganizing How-to Guide List​

The "How-to Guide" is also reorganized by topics. The existing tutorials are classified into the following sections for users to search quickly:

• Building REST APIs
• Creating Other Forms of APIS
• Accessing Databases
• Accessing Services
• Validating Data
• Securing Applications
• Deploying Applications
• Troubleshooting

You can visit the more organized contents in https://loopback.io/doc/en/lb4/.

Adding Property Types​

We added documentation for LoopBack 4 types including the syntax of model property definition in page https://loopback.io/doc/en/lb4/LoopBack-types.html.

Adding Application Layout​

We added project layout for LoopBack 4 applications in page https://loopback.io/doc/en/lb4/Loopback-application-layout.html, users can find each file's meaning and responsibility in the application scaffolded by lb4 app.

Cleaning up Extensions​

We are seeing more users creating extensions and it's a good time to make the extension creation experience easier and smoother. Therefore the extension generator and related documentations are updated to align with the latest code base. You can check the latest material in:

• Concept Component
• Creating Components

And run lb4 extension to create extensions with the new component template.

Renaming Legacy Juggler​

The term "legacy juggler bridge" might give the wrong impression to users that the loopback-datasource-juggler won't be supported or not working well because of the "legacy" word. So we removed the misleading word "legacy" across the documentations and CLI prompts.

loopback-datasource-juggler is still well maintained and we have a plan to modernize it. Feel free to join the discussion in issue #5956 if you are interested.

Investigation​

Restructuring Connector Reference​

The current connector contents are mixed with how-to guides, references and tutorials. The spike story 5961 came up with a better plan to reorganize them into the four quadrants layout:

• Connector concepts, its role in the framework and its relations to other artifacts will go to section "Concepts/Datasources".
• Datasource level configurations and features like migration/discovery will go to section "How-to Guides/Configuring DataSource".
• All the other connector specific tutorials will go to section "Tutorials/Connect to back-end tutorial".

Improving REST Experience​

REST Middleware​

A big feature took place in @loopback/rest to support more flexible ways to add express middleware for handling requests. PR #5366 added a middleware based sequence and wrapped existing actions as middleware. The new usage is documented in the following pages:

• Concept Middleware in LoopBack 4.
• Middleware-based Sequence for REST Server

Optimizing Middleware Based Sequence​

PR #6062 optimized middleware based sequence and its middleware providers to be singletons:

• MiddlewareSequence is now a singleton and it caches a list of middleware.
• Built-in middleware providers are now singletons.
• Validating sorted middleware groups is supported. Error will be reported if a middleware is unreachable.

Improving Serviceability of @loopback/rest​

There are several improvements made for easier debugging and error tracing in @loopback/rest module:

• PR #6159 added more debug information for request parsing, routing, and method invocation. The debugging keywords are loopback:rest:find-route, loopback:rest:invoke-method, and loopback:rest:parse-param.

• The route description is improved in PR #6188 to include the verb and the path.

• PR #6171 added HTTP server options and status information in the debug string. The debugging keyword is loopback:http-server.

Switching to DCO​

To make your contribution process simpler, we have changed the contribution method from CLA to DCO for loopback-next and most of the connector repositories. Be sure to sign off your commits using the -s flag or adding Signed-off-By: Name<Email> in the commit message. For more details, see https://loopback.io/doc/en/contrib/code-contrib.html.

Miscellaneous​

• PR #6172 makes sure the REST options are passed to http-server.

• PR #6105 Reworked the validation code to use exiting RestHttpErrors.invalidData error. This way the error object includes the parameter name in the error message & properties and has a machine-readable code property.

Community Contributions​

Thank you for the contribution coming from the community. Here are some of the contributions that we'd like highlight:

• Thanks to Nico Flaig's contribution! Now @loopback/authenticate supports applying multiple authentication strategies to one endpoint. The new syntax of decorator is:

  @authenticate(
    strategyOne | strategyOneWithOptions, 
    strategyTwo | strategyTwoWithOptions
  )
  myFunction() {}
  

  The new syntax is well documented in page Authentication Decorator.

• We appreciate Madaky's feature PR #5589 which adds the token refresh service in extension @loopback/authentication-jwt. You can check the new guide to try it.

• Many thanks to Rifa Achrinza's contribution in PR 6153. The order filter now supports string value as the shortcut in addition to the existing array value. You can specify an order filter as {order: 'name DESC'}.

Enriching LoopBack and its Community - You are Invited!​

As mentioned in our recent blog post, your contribution is important to make LoopBack a sustainable open source project.

Here is what you can do:

• Join LoopBack Slack community
• Look for first-contribution-friendly issues
• Give us feedback and join our discussion in our GitHub repo

Let's make LoopBack a better framework together!

Almost two years ago, LoopBack 4 was released and announced at Node+JS Interactive event. Thanks to your support, we now have over 110k downloads per month on npmjs.com and over 3000 GitHub stars on the loopback-next repo. Recently, we created the LoopBack Slack community to provide a platform for the community and us helping each other. We are glad to see an increasing engagement in that front as well!

With the core of the framework maturing and contributions shifting to the LoopBack extensions, we think LoopBack has entered a new stage and it's time to revisit our approach to planning work, delivering features, fixing bugs, and improving documentation.

A Short History of LoopBack 4​

As we started the rewrite of LoopBack from ground up back in early 2017 (see the kick-off post), it quickly became clear the scope is huge and we must be very disciplined in planning and scoping features if we want to reach a meaningful release in a reasonable time. We were working in short iterations, burning through a backlog of tasks we identified as required for the initial release. Eventually we published the first Developer Preview in November 2017, followed by more preview releases, until we finally released LoopBack 4 GA in October 2018. Keeping a tight control over backlog prioritization and milestone planning allowed us to achieve this great milestone.

Such a tight planning worked great while it was mostly the IBM core team working on the project. On the flip side, this process made it sometimes difficult to juggle our time between working on our roadmap vs helping community contributors; and often created the impression that the core team will eventually implement all missing features, given enough time, and community contributions are not really necessary. This was acceptable while the framework offered only a limited subset of features needed to build real applications, because there were only few early adopters to support and it was indeed the core team that was contributing most of the improvements.

As more and more users discover and try LoopBack, they may find feature gaps, identify bugs, or even come up great ideas. If the perception is that somebody else (the core team) will eventually implement those features, then there are little incentives for users to step up and join the project as contributors. As a result, the number of maintainers is not keeping up with the growing number of users, leading to ever-increasing load on existing maintainers and eventually maintainers burning out or leaving the project. (You can read more on this topic in Healthy Open Source and Sustaining and growing LoopBack as a successful open source project).

Many of us has experienced this ourselves in the past, when LoopBack 3 got to the stage where the maintainers were overwhelmed with the amount of incoming issues and pull requests. We feel it's time to turn the ship around and make sure we don't repeat the same mistakes in LoopBack 4. As LoopBack 4 user base grows, it is essential to grow our contributor community joining forces to enhance the framework together.

Encourage More Community Contributions​

We have been always actively looking for new ways to attract more contributions from our community and grow contributors into maintainers.

To make it easy for our users to find easy-to-implement improvements to contribute, we are adding good first issue and help wanted labels on GitHub issues, and listing items we'd like to see progress in our roadmaps and milestones.

In addition, we recently made an announcement about switching the contribution method to Developer Certificate of Origin (DCO) from Contributor License Agreement (CLA). We hope this will make the contribution process easier for you.

Going forward, we would like to focus more on enabling more of you to contribute by mentoring and coaching them to complete their PRs and providing technical guidance on their work if needed. We would also like to create more examples and starter code for experimental features, and invite the community to enhance those features collectively.

To further encourage community contributions, we are going to open our planning process too and start building the roadmap together with our community, based on what tasks individual contributors would like to work on.

Inspire More Community Extensions​

One of the strengths of LoopBack 4 is its extensibility. You can create extensions to extend the programming model and integration capability of the LoopBack 4 framework.

We created a number of extensions, for example, the recently published TypeORM and pooling service extensions. These can be served as references to inspire you to build extensions to fit your needs.

Moreover, we'll be working on cleaning up the extension template and documentation, so that the developer experience of building an extension is smoother.

At the same time, we're happy to see more extensions built by the community, see the community extensions page. Let's build this list together by submitting a PR to include your extensions!

Potential Work under Our Radar​

We have been investigating a few areas that can further improve LoopBack 4 based on our visions, even more importantly community feedbacks. There are some ideas for inspiration.

Modernizing the juggler has been under our radar. We would like to position LoopBack as the composition layer that brings API/microservice stories together. It will include built-in capabilities such as REST API and Data/Service access as well as integration with other frameworks. We're planning to publish a blog to cover that. Stay tuned.

Below are areas that we've done some initial investigation/implementation and would like to invite you to join us to build a more complete story. It includes continuing to improve our documentation and building more education materials. Likewise, we'll be publishing blog posts to share our plans and visions in the following areas:

• Multi-tenancy
• Web socket
• Kafka integration
• GraphQL
• gRPC

Conclusion​

Your contribution is important to make LoopBack a sustainable open source project. We hope our plans to adopt DCO, improve the extension development experience and focus on enabling contributors would make your contribution experience smoother and better. We are also planning on sharing our views on a few technologies.

Here is what you can do:

• Join LoopBack Slack community
• Look for first-contribution-friendly issues
• Give us feedback and join our discussion in our GitHub repo

Let's make LoopBack a better framework together!

Welcome to the July edition of the "Community Q&A Monthly Digest", curating some of the Q&A that we think it might be helpful to you. Let's take a look.

Question: Is there a built-in support in LB4 for database retries if the db responds with 429 for example? Or is it possible to overwrite a single method to implement this for all db operations similiar to how entityToData can be overwriten if data should be added to all create/update operations.

Answer: It's better to intercept execution errors inside the datasource, not at repository level. I created a small example to demonstrate the approach. In a real app, I would extract the code into a mixin that can be applied on any DataSource class. https://gist.github.com/bajtos/2379d7c6df31e477aaa3a3f6ea87886c

Question: Is it possible to connect my API to a webhook, so that when an event is triggered, it notifies my API? What documentation could I read about doing this?

Answer: A webhook is just another HTTP request. Depending on the architecture of the lb4 app, this request can be done in a Service, an Interceptor, or a Controller, using either the built-in Node.js API or third-party HTTP request modules such as Axios. Besides that, no special configuration is needed for web hooks. 

Question: How to implement findOrCreate instead await exists + await create?

Answer: You can extend DefaultCrudRepository with findOrCreate ’s implementation. Then your repositories extend the custom one. Similar to how AccountRepository extends MyDefaultCrudRepository in the tutorial https://loopback.io/doc/en/lb4/Repositories.html#define-repositories.

Question: I started using Loopback 4. How to redirect home screen of LB4 to angular 8 running on some other port?

Answer: It should be possible to replace the .static function in the app class with .redirect: https://loopback.io/doc/en/lb4/apidocs.rest.restapplication.redirect.html.

Question: The compiler throws the error error TS2322: Type 'string' is not assignable to type PredicateComparison<..> when I tried some repository CRUD methods. Is it a bug or anything wrong with my setup?

Answer: It is a type issue. For repository CRUD methods, they may take in Filter or Where type parameters. For those cases, you will need to specify the type of it, for example:

const userCount = await this.userRepository.count({tags: 'admin'} as Where<User>);
const vipUser = await this.userRepository.find({where:{tags: 'vip'}} as Filter<User>);

Question: We have a project which includes multi-tenancy based multi-database pattern (We have Common DB which stores Client Informations (Users, DB configs etc), and each clients has own database). How can I perform switching datasource dynamically with the multi-tenancy based project?

Answer: You can check out the multi-tenancy example and the GH issue that discusses about multi-tenancy and dynamic schema selection. You can create datasources at runtime. Meanwhile, if the number of dbs is limited, you can define them upfront and reuse them, see Creating a datasource at runtime. Then the tenant strategy can inject a repository talking to your common DB to load configs per logged in user.

Interested to Join our Slack Workspace?​

Simply click this invitation link to join. You can also find more channel details here: https://github.com/strongloop/loopback-next/issues/5048.

We can't believe that it is already August! Let's check out the work we did in July:

• HasManyThrough Relation
• Documentation Enhancements
• Reorganize Code and Docs Along Abstraction Levels
• Bug Fixes
• Community Contribution

HasManyThrough Relation​

A HasManyThrough relation sets up a many-to-many connection through another model. A real-world example is a doctor has many patients through appointments. The relation can be defined with @hasMany decorator as:

  //...
  @hasMany(() => Patient, {through: {model: () => Appointment}})
  patients: Patient[];

We finished most of implementation in June, and we added HasManyThrough to the relation CLI and also related documentation so that users could learn it better. Please make sure you have @loopback/repository with version 2.10.0 or higher installed.

Documentation​

The hasManyThrough Relation page is being added under Relations page. We introduced the use cases, definitions, and examples of how you can customize the relation to meet your requirements. Nevertheless, as mentioned in the docs, because it is an experimental feature, there are some missing functionalities such as inclusionResolver. Feel free to join discussions on GitHub or even contribute :D

CLI Command​

Command line interfaces (CLI) is a convenient tool to help you create artifacts quickly. We added hasManyThrough relation to lb4 relation command. With a few prompts, you can define a hasManyThrough relation easily:

$ lb4 relation
? Please select the relation type hasManyThrough
? Please select source model Doctor
? Please select target model Patient
? Please select through model Appointment
? Foreign key name that references the source model to define on the through model
 doctorId
? Foreign key name that references the target model to define on the through model
 patientId
? Source property name for the relation getter (will be the relation name)
 patients

Don't forget to install the latest @loopback/cli to try it out!

Documentation Enhancements​

One of our recent targets is to upgrade the documentation system. As you can see on the site, we reorganized most of the items in sidebar. In the overview page, the section How is our documentation organized introduces how you can find documentation in the four quadrants.

Besides improving the structure, here are some documentation enhancements we'd like to share:

Apply JWT Authentication Component to Shopping Example​

The @loopback/authentication-jwt component was created to make adding JWT authentication to your application earlier. We've applied it to the shopping example. To find out more, see the JWT authentication extension documentation page.

How to Access Multiple Models in a Single Transaction​

A transaction is a sequence of data operations performed as a single logical unit of work. LoopBack 4 has many relational database connectors support such logic requirements. We added a section Accessing multiple models inside one transaction to show how it can be achieved.

Custom AJV Validation​

We realized that the current AJV Validation documentation is missing a crucial information piece on how to enable custom validation and error messages. Please check out the section Custom validation rules and error messages and Validation example for details.

Reorganize Code and Docs Along Abstraction Levels​

As LoopBack 4 is growing larger, we decide to hide some low-level tools from users so that the framework looks neat and friendly. In July, we hid module @loopback/openapi-v3 as it can be loaded from @loopback/rest.

We removed @loopback/openapi-v3 from dependencies and also our CLI template dependencies. If you check the page Extending OpenAPI Specification or other related pages, you will notice it is now hidden and replaced by @loopback/rest.

Execute Raw NoSQL Queries​

If you have a SQL database as back-end service, you can execute raw queries using the execute method that we have in Repository, and it works great. Unfortunately, execute does not work for NoSQL connectors such as MongoDB as they require more than just a command string and args array.

In July, we started working on how we can improve LB4 API and MongoDB connector API to make it easy to execute raw MongoDB commands. We added a DataSource.execute method to the Juggler, and leveraged it to support different execute styles. We also added support for non-SQL variants of Repository.execute() in the loopback/repository module. More works will be done in August. You can check the progress in story Execute raw NoSQL queries on GitHub if you're interested.

Bug Fixes​

There was a story that a boy woke up in one morning and found himself transformed into a gigantic bug. We don't want that to happen, so we fixed a few bugs in July:

Unable to Perform Nested Filters​

As we added the support for coercing query object with schema last month, it exposed a bug that the nested scope filters don't have the correct constraints. It is being fixed and released in @loopback/rest@5.2.1. Now you can include nested navigational properties using filter like:

{
  include: [
    {
      relation: "orders",
      scope: {
        // nested relation
        include: [
          {
            relation: "someOtherRelation",
          },
  ...
}

Query with Dollar Signs in MongoDB Connector​

If you're using MongoDB, you would be used to have dollar signs ($) in your queries. However, the dollar signs are not needed in LB4 general queries, and that's why loopback-mongodb-connector users get confused usually. To improve the user experience, we made some changes in the connector loopback-mongodb-connector, so that the connector users won't get errors even if the queries contain extra dollar signs. The change is released in @loopback-connector-mongodb@5.3.0

Community Contribution​

New Community Maintainers​

We are glad to have @nabdelgadir and @madaky to be one of our community maintainers. We appreciate your great work you've done and welcome to the team.

Highlights​

• As LoopBack 4 is designed to be more scalable and extensible, there are numbers of extensions created by the open source community. You may find some interesting and helpful extensions under the Community extensions page. We are also considering adding example usages of LB4 from the community. Please let us know if you got any great extensions or examples you would like to share with us!
• The community user @zyqVizzzzz translated several tutorials for LB4 in Chinese. They can be found in the page 教程（Tutorials）. We really appreciate it! If you're interested in translating LB4 documentation, the instructions can be found in the page Translation.

In order to make your contribution process simpler, we will be gradually changing the contribution method from Contribution License Agreement (CLA) to Developer Certificate of Origin (DCO). Take a look at this blog to find out what the changes are and what it means to you.

What's Next?​

If you're interested in what we're working on next, you can check out the August Milestone.

Call to Action​

In 2020, we look forward to helping you and seeing you around! LoopBack's success depends on you. We appreciate your continuous support and engagement to make LoopBack even better and meaningful for your API creation experience. Here's how you can join us and help the project:

• Report issues.
• Contribute code and documentation.
• Open a pull request on one of our "good first issues".
• Join our user group.

Since the beginning of the LoopBack project, we have been using the Contributor License Agreement (CLA) as the contribution method. Contributors need to sign each CLA for each LoopBack repository they're contributing. To simplify the contribution process and encourage community contributions, we are planning to gradually switch to use Developer Certificate of Origin (DCO) as the contribution method.

What Is Developer Certificate of Origin (DCO)?​

As an alternative to CLA, a Developer Ceritifcate of Origin (DCO) is a more lightweight contribution method. According to Wikipedia:

Instead a signed legal contract, a DCO is an affirmation that the source code being submitted originated from the developer, or that the developer has permission to submit the code.

The full text of DCO can be found: https://developercertificate.org/.

Why Are We Switching?​

Community contributions are vital to the success of LoopBack. Since DCO simply needs your affirmation that you are the one who is submitting the code, we hope this switch would make the contribution process simpler and thus encourages more contributions from you!

In addition, this change can help us to reduce the infrastructure cost, including the team's time and effort, to maintain the CLA server.

What Does It Mean To You?​

Currently, the loopback4-example-shopping is already using DCO.

To sign off the commit, you can:

git commit -s -m "feat: my commit message"

Over the next little while, we'll start the switch for the repositories with the most community contributions, namely loopback-next, loopback.io and loopback-datasource-juggler, then we'll roll it out for the connector repos.

Start Contributing!​

You are more than welcome to contribute on something that you find it relevant and interesting to you. If you're simply looking for items that we want help, you can look for GitHub issues with help wanted or good first issue labels.

More questions? Feel free to ask in the #loopback-contributors channel of the LoopBack Slack community.

Welcome back to the "Community Q&A Monthly Digest", in which we highlight some of the questions and answers in our LoopBack Slack community here.

Question: Has anyone implemented Casbin on a brand new project? or is there a good tutorial for lb4? I need to have some rbac / roles system in an app.. or what would you suggest to achieve that?

Answer: We have an access control example uses casbin, see the access-control-migration example and its tutorial. The logic on casbin side is only a prototype, the example mainly shows the integration between casbin and LoopBack authorization system.

Question: I am new to LoopBack and so far I really like what it has to offer. I was wondering if anyone knows of a good online course to learn LoopBack. I have worked through the basic tutorials found in the documentation, but I find it easier to listen and follow along to videos.

Answer: Recently one of our community member posts a YouTube tutorial for LoopBack 4 beginners. There is another series of educational videos on a LoopBack introduction and installation.

From our side, there are a few recent videos on our StrongLoop YouTube channel and we're trying to add more. Hope it helps.

Question: I am trying to disable the openapi.json from showing in my loopback 4 application and its not working. I was able to disable the explorer. Any ideas?

Answer: You can use openApiSpec: {disabled: true} in index.ts. i.e.

const config = {
    rest: {
      //..
      openApiSpec: {
        disabled: true
        //..
      },
    },
  };

Question: Does Loopback 4 support extracting cookies from the header? Currently I had to integrate Express server to achieve this.

Answer: You can use express middleware like http://expressjs.com/en/resources/middleware/cookie-parser.html see how to use middleware in https://loopback.io/doc/en/lb4/Express-middleware.html.

Question: Is there a quick way to generate timestamp? Like at the model level generated:true?

Answer: I recommend to use defaultFn set to one of the following string values:

• "guid": generate a new globally unique identifier (GUID) using the computer MAC address and current time (UUID version 1).
• "uuid": generate a new universally unique identifier (UUID) using the computer MAC address and current time (UUID version 1).
• "uuidv4": generate a new universally unique identifier using the UUID version 4 algorithm.
• "now": use the current date and time as returned by new Date()

See also https://github.com/strongloop/loopback/issues/292 and https://loopback.io/doc/en/lb4/Model.html#property-decorator.

It would be great to capture these options in our TypeScript definitions, see https://github.com/strongloop/loopback-next/blob/ae6427322451c914ae54f44dbb656981e7fbbb81/packages/repository/src/model.ts#L34-L42.

Question: Can I use MongoDB update operators in LoopBack apps? How can I enable it?

Answer: Yes, except comparison and logical operators, the mongo connector also supports MongoDB update operators such as max, rename, etc. You will need to set the flag allowExtendedOperators to true in the datasource configuration. You can find details and examples at MongoDB connector - update operators.

Interested to Join our Slack Workspace?​

Simply click this invitation link to join. You can also find more channel details here: https://github.com/strongloop/loopback-next/issues/5048.

Over the recent months, this global pandemic has affected our lives in different ways; we hope you all stay safe during these difficult times. The LoopBack team has adapted to new ways of working, including virtually and in new settings. Even though it could be challenging sometimes, we are glad that we were able to complete most of our Q2 plan. Thanks to all the support from the team and the community!

Here's a brief look at the Q2 summary:

• Migration Guide
• Enhancing Documentation
• Leveraging Authentication System
• APIC/LB4 Integration
• Other Highlights
• Building LoopBack Community

Migration Guide​

One of our main targets in Q2 was to finish the migration guide, and we did it! We accomplished all the items on the migration plan. The Migration guide can be found easily on the LB4 home page. We have instructions that helps you migrate various artifacts and also have docs to explain similarities and differences between LB3 and LB4. From request/response infrastructure to datasource setup, from model definitions to the authentication and authorization, we hope the guide is useful for you when migrating your LoopBack 3 applications to LoopBack 4.

Enhancing Documentation​

New Documentation Structure​

This quarter, one of our targets was to upgrade the documentation system. As we are adding more features and documentation to LoopBack 4, the abundant amount of sidebar entries was overwhelming and difficult to navigate with the old documentation system. We reorganized most of them into the following four parts:

• "Tutorials"
• "How-to guides"
• "Behind the scenes"
• "References guides"

For example, if you'd like to learn how you can secure your LoopBack 4 application, now you can find it easily under the "Tutorials" sections instead of searching through the whole path "Concept -> Authentication -> Authentication tutorial".

Moreover, we also started working on reorganizing most of our documentation to focus on framework-level APIs and de-emphasizing the lower-level building blocks to reduce the complexity. For example, we removed @loopback/express from framework-level documentation and replaced references to use @loopback/rest instead.

This is just the first step of our long journey of improving the documentation system. Please let us know if you have any feedback.

Rewriting your favorite LB3 content to LoopBack 4​

We've been using shared content for some topics in both LB3 and LB4, but this might be confusing if the user is not familiar with LB3. To reduce the gap between these two versions, we also rewrote some documentation from LB3 in LB4 style. For example, now you can check usage examples written in LB4 style for the Filters under the page Working with data. What's more is that we also created tutorials for connecting to MySQL, Oracle, PostgreSQL, and MongoDB databases. By following the steps in these tutorials, you'll find it easy to connect to databases with LB4 applications.

Leveraging Authentication System​

The authentication system has changed a lot since it was being used as an experimental feature. It is now more reliable and flexible. We improved it in the following aspects:

Examples​

We added two examples for different authentication strategies:

• TODO example with JWT demos enabling JWT authentication in the Todo application. This is a good example for beginners to follow the authentication system.

• Passport Login example shows how to use Passport Strategies in LoopBack 4. If you are using the loopback-component-passport in LoopBack 3, this example can help you migrate your application to LoopBack 4.

Documentation​

We reorganized the authentication documentation to make it more easy to adopt. Instead of throwing all the details to users, now the authentication docs starts with a simple high-level explanation, then it walks through users with several examples with different difficulties to show what the system is capable of and how they can be achieved.

Besides, as we mentioned above, we also added page Migrating authentication and authorization as part of the migration plan as well.

APIC/LB4 Integration​

API Connect is a complete, intuitive and scalable API platform provided by IBM.

In Q2, we completed the integration of LoopBack 4 with API Connect v10 which was released in June. When a LoopBack application is scaffolded through the APIC toolkit, the LoopBack-generated OpenAPIv3 spec comes with API Connect specific metadata added, thanks to the LoopBack APIConnect extension. If you're interested, we've been preparing an article on how you can take the APIs created from LoopBack and import them into API Connect for API management. Stay tuned!

Other Highlights​

Here are some highlights of our work we would like to share!

Supporting TypeORM​

You might decide to use an alternative ORM/ODM in your LoopBack 4 application, and LoopBack 4 also has such flexibility as it no longer expects you to provide your data in its own custom Model format for routing purposes, which means you are free to alter your classes to suit these ORMs/ODMs.

TypeORM is an ORM that can run in NodeJS and others platforms and can be used with TypeScript and JavaScript, which fits LoopBack 4 well. We implemented initial support for TypeORM in LoopBack 4 in the @loopback/typeorm package. Please check the README file for the usage and limitations.

Express Middleware​

LoopBack 4 leverages Express behind the scenes for its REST server implementation. The new Express Package, has enabled injecting single and multiple express middleware functions as Interceptors into Controller invocations and also as a middleware step in the application Sequence.

Component Application Booter​

Sometimes it might be the case that we want to break our complex application into multiple smaller LoopBack applications. The component application booter composes these sub applications into the main application. This is helpful for building a scalable micro-services application. See the page Booting an Application.

HasManyThrough Relation​

With help from the community users, the experimental feature HasManyThrough relation is added to LB4. Currently it only has some basic functionalities. The documentation and related CLI will be updated in the near future.

Run Tests in Parallel​

We upgraded mocha to the new version 8, and it enable parallel execution of Mocha tests. With the option, we can control the number of worker processes and make the testing process more efficient. Details can be found in Running tests section.

Extensions​

Extensions/Extension points is one of the main features of LB4 to make the application extensible. We added the following two extensions in Q2:

• JWT authentication: as the authentication system gets popular and more solid, we extracted the JWT authentication system into a separate extension package as an experimental feature, so that users can quickly mount a component to try out the feature. Check authentication-jwt for details.

• LoopBack APIConnect extension: the LoopBack APIConnect extension is ready for use. It provides ApiConnectComponent that adds an OASEnhencer extension to contribute x-ibm-configuration to the OpenAPI spec generated by LoopBack applications.

Building LoopBack Community​

We're happy to see more users/developers join our community. We appreciate all the help! We've opened a public Slack channel so that developers can ask questions, discuss issues, and share their knowledge to help each other easily.

We also had a several video-calls with LoopBack maintainers. It's nice to get to know each other, share the plans & visions and discuss topics by talking together. Let's continue building LoopBack a better framework together.

Wanna join us? Yes! You're invited 👉 Join LoopBack Channel on Slack.

Previous Milestone Blogs​

There are many more accomplishments that cannot be captured in this blog, make sure you check out our previously published monthly milestone blog posts in Q2 for more details:

• April 2020
• May 2020
• June 2020

What's Next?​

We have published a blog LoopBack - 2020 Goals and Focus about our plans this year. Here is a summary of the Q3 2020 roadmap:

• finish migration guide for both general runtime and authentication & authorization
• continue with API Connect and LoopBack integration
• look into feature parity gaps that are highly requested by users

Call to Action​

In 2020, we look forward to helping you and seeing you around! LoopBack's success depends on you. We appreciate your continuous support and engagement to make LoopBack even better and meaningful for your API creation experience. Here's how you can join us and help the project:

• Report issues.
• Contribute code and documentation.
• Open a pull request on one of our "good first issues".
• Join our user group.

Documentation restructuring, TypeORM support, and HasManyThrough were the three main accomplishments in the month of June. Based on the community feedback, documentation improvement remains our number one priority in the coming month. Besides, while welcoming Nathan Chen join as a maintainer of the strong-globalize repo, we said farewell to Deepak.

Here is what we did in the month June:

• Documentation Improvements
• HasManyThrough
• TypeORM Support
• Miscellaneous

Documentation Improvements​

New Documentation Structure​

When writing documentation for new features, we were often struggling to find the right place to put the content and the right form to frame the information. Recently, we discovered a documentation system based on four different functions. It explains why we were struggling and provides a structure to guide us when writing new content.

Documentation needs to include and be structured around its four different functions: tutorials, how-to guides, technical reference and explanation. Each of them requires a distinct mode of writing. People working with software need these four different kinds of documentation at different times, in different circumstances - so software usually needs them all, and they should all be integrated into your documentation.

In June, we explored how to apply this documentation system to our content and implemented first high-level changes in the way how our content is organized. Check out loopback-next#5549 to find more resources about our new documentation system.

In a series of incremental pull requests, we reworked our documentation structure as follows:

• Renamed "Usage scenarios" to "How-to guides" to make it clear what kind of content is there.
• Placed all explanation-related pages in "Behind the scenes" section and removed the section "Key concepts".
• Relocated all reference guides to be nested under "Reference guides". We moved pages like "Error handling" and "Reserved binding keys" to references guides to make them easier to find.
• Moved pages from "Using components" to "How-to guides".
• Added support for sidebar sections that are just grouping related pages together but don't have a page of their own. This allowed us to remove few section pages that were rather anemic: "Access databases", "Reference guides", "How-to guides".
• Reworked the "Server" page in "Behind the scenes" because there was a mix of different kinds of content in the page. We extracted some of the guides into new pages nested under "How-to guides".

The re-organized documentation is already live at loopback.io, take a look and let us know what do you think!

Now that the new structure is in place, we are going to gradually review and update existing documentation content to align it with the new system. You can find the list of relevant tasks in loopback-next#5113. As always, your help is welcome!

Alignment Along Abstraction Levels​

As we were incrementally adding new features to the framework and extracting building blocks into standalone packages, our documentation ended up describing concepts from different abstraction layers in the same place, mixing information for framework users with references to low-level building blocks. This resulted in a steep learning curve for new users, because there were so many concept and packages to learn about!

In June, we reorganized most of our documentation to focus on framework-level APIs and deemphasize lower-level building blocks. As a result, we updated our developer documentation to describe which packages are considered as building blocks, see Organization of content. We also:

• updated our packages and documentation pages to use @loopback/core instead of @loopback/context
• removed @loopback/metadata from framework-level documentation and replaced references to use @loopback/core instead
• removed @loopback/express from framework-level documentation and replaced references to use @loopback/rest instead

Now we need to update places referring to @loopback/openapi-v3, as discussed in loopback-next5692. Want to contribute those changes yourself? Submit a PR today!

Refactoring of Authentication-related Documentation​

We refactored the authentication documentation so that it is easier for beginners to follow. As the new entry page, the authentication overview page describes a typical scenario for securing APIs and it also helps you understand what "authentication" means in LoopBack 4. Next you can follow a simple hands-on tutorial secure your LoopBack 4 application with JWT authentication to start exploring this feature. Then you can gradually learn the authentication system's mechanism and how to implement your own authentication strategies.

Adding LoopBack 4 Content to Connector Pages​

As the continuation of improving connector documentation, after updating the PostgreSQL connector, we updated the connector page and added three more tutorials for MySQL, Oracle, and MongoDB connectors in June. By walking you through the steps of creating a LB4 application and connecting to a certain database, we hope new users find the tutorial helpful to adopt LoopBack 4 better. Besides the basic setup steps, we also added some sections to explain those questions that are being asked a lot from the community. Check out these documentations under Database connectors.

HasManyThrough​

A HasManyThrough relation sets up a many-to-many connection through another model. At the moment, LB4 only supports three basic relations: HasMany, BelongsTo, and HasOne.

Thanks to the initial work by codejamninja and derdeka, we have a working prototype of the feature.

While functional, the PR is pretty huge and some of the parts are up for discussion. As a result, we started to extract the core parts of the implementation into smaller PRs so that it's easier for review. In June, we had the basic operations working and tests are added. As the next step, we'll be adding documentation.

Stay tuned with the progress by going to loopback-next #5835.

TypeORM Support​

We have implemented initial support for TypeORM in LoopBack. All it takes to enable TypeORM is to compose your app with the TypeOrmMixin mixin.

import {BootMixin} from '@loopback/boot';
import {RestApplication} from '@loopback/rest';
import {TypeOrmMixin} from '@loopback/typeorm';
export class MyApplication extends BootMixin(TypeOrmMixin(RestApplication)) {
  ...
}

For details about using TypeORM with LoopBack, refer to the @loopback/typeorm doc.

Complete support for TypeORM is a significant amount of work. While the initial work is done, we're looking for ways to improve the implementation in the following areas.

1. Complete TypeORM to OpenAPI data type conversion (currently only number, string, and boolean are supported)
2. Full JSON/OpenAPI schema for models, including variants like with/without id, with/without relations, partial, etc.
3. Json/OpenAPI schema to describe the supported filter format
4. Support for LoopBack-style filters
5. Custom repository classes (e.g. to implement bookRepo.findByTitle(title)).
6. Database migration

Miscellaneous​

We upgraded mocha to the new version 8. This version brings support for running tests in parallel (yay!), but also drops support for --opts argument and test/mocha.opts file. See Mocha 8.0.0 release notes for the full list of breaking changes and instructions on migrating existing projects. Our changes were introduced by loopback-next#5750 and loopback-next#5710; and published in @loopback/build version 6.0.0.

Miroslav benchmarked the performance of LoopBack and found an opportunity for a quick but significant improvement. By changing the algorithm used in @loopback/context to generate unique context instance names, we managed to improve the performance of our REST API layer by 45%! Learn more in the blog post How We Improved LoopBack REST Performance by 45%.

A new method exportOpenApiSpec() was added to the RestServer for generating OpenAPI specs in JSON or YAML format. This method can be called from the project directory by running the openapi-spec script.

When a binding key is not bound,ResolutionError now captures more contextual information. Earlier it used to print a long stack trace and was not easy to find out where the failure happened.

The implementation of binding cache was improved to prevent race conditions and better handle bindings in async conditions.

CoreBindings.APPLICATION_INSTANCE now has corresponding @config() decorator.

July Milestones​

In the month of July we will continue focusing on improving the documentation. You can see the whole list on the July milestone issue.

There is also ongoing work to have native GraphQL support and a new extension for pooling service. Your feedback is welcome.

Welcome and Goodbyes​

We're pleased to welcome Nathan Chen as the maintainer of the strong-globalize repo. Thank you Nathan for all the good work you've done. On the other hand, it's sad to see Deepak leaving the LoopBack team. We wish him best of luck in his new adventure.

Call to Action​

In 2020, we look forward to helping you and seeing you around! LoopBack's success depends on you. We appreciate your continuous support and engagement to make LoopBack even better and meaningful for your API creation experience. Here's how you can join us and help the project:

• Report issues.
• Contribute code and documentation.
• Open a pull request on one of our "good first issues".
• Join our user group.

Since we made the LoopBack Slack community available, we are happy to see more and more users are joining. Let's see some of the questions and answers that we've highlighted below.

Question: In the Model documentation page, it says "To define a model for use with the juggler bridge, extend your classes from Entity". What's the juggler bridge?

Answer: the Juggler bridge is used to bridge the gap between @loopback/repository and loopback-datasource-juggler. The former is used by LoopBack 4 to help define Models, Repositories, etc. It also allows for cross-datasource relations, etc. as they are enforced at the application level instead of the database.

The latter is the ORM/ODM that builds the queries and interacts with the database. It's from LoopBack 3 and is probably the only major component that didn't get revamped to keep backwards-compatibility.

Hence, the Juggler bridge helps bridge the gaps between these Node.js packages.

Entity is, at it's core, a model that has an ID property. Looking at the source code for Entity, there's quite a bit of boilerplate code added.

Question: Is there a way to change the application port to string ? I am trying to deploy the application under Azure web app where the port is a string.

Answer: Use port: +(process.env.BILLING_PORT || 3000),. The + converts a string to number. For the pipe, you should use path property instead of port. See https://github.com/strongloop/loopback-next/blob/master/packages/http-server/src/tests/integration/http-server.integration.ts#L272.

Question: I have a model with a field which is defined as “number”. Working with Postgres. How should I define it to have the field as a double and not an integer ?

Answer: You can specify the dataType field to define a certain type of that column. For type Double, for example,

@model()
export class Item extends Entity {
  @property({
    type: 'number',
    id: true,
    generated: false,
  })
  id?: number;
  @property({
    type: 'number',
    postgresql: {
      dataType: 'double precision',
    },
  })
  price?: number;
....

Then run npm run build and then npm run migrate commands, the table should have columns:

price       |                | double precision

Besides the data type, LB4 also allows you to describe tables via the model definition and/or property definition. See Data Mapping Properties for information.

Question: Is there client sdk for lb4 for api code generation? I tried with swagger codegen, but the generated code seems doesn't work.

Answer: You should try lb4 openapi --client. It generates strongly-typed LoopBack service proxies over openapi spec using TypeScript. We use it to generate SDKs in TS.

Interested to Join our Slack Workspace?​

Simply click this invitation link to join. You can also find more channel details here: https://github.com/strongloop/loopback-next/issues/5048.

Recently, I measured the performance of LoopBack 4 and found an opportunity for an easy but significant improvement in the way how we are building per-request context instances.

I have been always interested in performance, from high-level design patterns like caching & memoization, to micro-optimizations at language level (anybody remembers CrankShaftScript from Node.js 0.10 days?), all the way down to Mechanical Sympathy.

Since we started rewritting LoopBack from scratch in 2016/17, our primary focus was on features; performance aspects were a bit off the radar. (Not entirely, we were careful to design our HTTP routing layer to avoid the low performance of regexp-matching approach used by Express.) Now that LoopBack 4 is pretty mature, I though it's a good time to take a quick look on how fast is our framework.

To quickly get a high-level overview, I installed Clinic.js and benchmarked our TodoList example application. I used the following TodoList query (filter) for all benchmarks:

{
  "include": [
    {
      "relation": "todos"
    }
  ]
}

The filter value needs to be URL-encoded, producing the following URL to pass to Clinic.js - let's save it to a shell variable for later use.

$ URL="/todo-lists?filter=%7B%0A%20%20%22include%22%3A%20%5B%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%22relation%22%3A%20%22todos%22%0A%20%20%20%20%7D%0A%20%20%5D%0A%7D"

Clinic.js Doctor​

The Doctor component performs an overall diagnosis looking for common anti-patterns. After installing Clinic.js globally, I ran the following command in examples/todo-list directory of loopback-next monorepo:

$ clinic doctor --debug --autocannon $URL -- node .
Server is running at http://127.0.0.1:3000
Running 10s test @ http://localhost:3000/todo-lists?filter=(...)
10 connections
(...)
18k requests in 11.05s, 11.1 MB read
Analysing data
Generated HTML file is file:///(...)/todo-list/.clinic/41598.clinic-doctor.html
You can use this command to upload it:
clinic upload .clinic/41598.clinic-doctor

The report says there were no issue detected, hooray!

A closer inspection shows that our process is consuming quite a lot of memory. We don't have any memory leaks, which is most important. However, excessive allocations put more pressure on garbage collector which does impact application's performance. Let's set the memory usage aside for now and check how much time is the application spending on waiting for asynchronous operations.

Clinic.js Bubbleprof​

Quoting from ThoughtWorks Technology Radar:

Clinic.js Bubbleprof represents visually the async operations in Node.js processes, drawing a map of delays in the application's flow. We like this tool because it helps developers to easily identify and prioritize what to improve in the code.

Let's see how the bubbles look like for a LoopBack application!

$ clinic bubbleprof --debug --autocannon $URL -- node .
Warning: The code is transpiled, bubbleprof does not support source maps yet.
Server is running at http://127.0.0.1:3000
Running 10s test @ http://localhost:3000/todo-lists?filter=(...)
10 connections
(...)
2k requests in 10.06s, 1.28 MB read
Analysing data
Generated HTML file is file:///(...)/todo-list/.clinic/42229.clinic-bubbleprof.html
You can use this command to upload it:
clinic upload .clinic/42229.clinic-bubbleprof

There isn't much to see in the report, the application spent less than 20ms waiting for async operations. I guess that was kind of expected considering that our example application is using in-memory storage and not communicating with any external service.

Clinic.js Flame​

The last item in Clinic.js toolbox is Flame. Quoting from Clinic's website:

(...) flamegraphs are a visualization of profiled software, allowing the most frequent code-paths to be identified quickly and accurately. Clinic.js Flame is specifically for Node.js and is built into Clinic.js. It collects metrics using by CPU sampling, then tracks top-of-the-stack frequency and creates flamegraphs.

Can we find anything interesting in the flames? Let's see.

$ clinic flame --debug --autocannon $URL -- node .
Server is running at http://127.0.0.1:3000
Running 10s test @ http://localhost:3000/todo-lists?filter=(...)
10 connections
15k requests in 10.03s, 9.44 MB read
Analysing data
Generated HTML file is file:///(...)/todo-list/.clinic/42454.clinic-flame.html
You can use this command to upload it:
clinic upload .clinic/42454.clinic-flame

There is a lot of information packaged into a flame graph. Initially, Clinic.js is selecting the hottest frame - the stack that was observed most often while running the application. In our case, the hottest frame is pointing to Node.js internals dealing with writing data to streams.

There isn't much we can do about Node.js streams. Our application is writing HTTP responses so it has to spend some time writing the data. The third hottest frame is parseQueryStringValues from the module qs, this is again not something we can easily improve. Let's remove all components except dist in the check-box list at the bottom of the screen to focus on LoopBack code only.

Now the list of hot frames looks much more actionable! Here are the top entries:

1. handle in sequence.js was 11.4% of time on top of stack
2. buildLookupMap in relation.helpers.js was 6.3% of time on top of stack
3. findByForeignKeys in relation.helpers.js was 5.7% of time on top of stack

And so the list goes on. The entry number 7 caught my attention: the application is spending 1.3% of the time in generateName from context.js. That's suspicious, why is generating context names so expensive?

It turns out we are generating unique context names to make it easier to debug binding-related issues. Our initial implementation was based on UUID version 4 (random) algorithm. Universally unique ids are great when you are aggregating debug logs from a mesh of microservices. However, most of the time, context names are just a hidden property of context instances that's not surfaced anywhere. Applications shouldn't be paying performance tax for something they don't use. Let's see if we can find a better solution.

UUID Alternatives​

What other options are there to generate unique ids?

• We can use UUID version 1 that's based on date-time and MAC address.
• If we didn't need universally unique values, then a simple counter (perhaps prefixed with the current process id) could be a viable alternative.
• Surely somebody else must have encountered this problem before us. Aren't there any fast id generators on npmjs.com? Of course there are! The search for "fast unique id" returned hyperid as the best match.

Let's compare the performance of these alternatives. I wrote a simple benchmark which you can find in this Gist and measured the following data:

Initially, I wanted to use a numeric counter because it has the best performance. However, that would mean losing uniqueness of context names. At the end, I decided to go with hyperid. It combines UUID v4 with a counter to achieve almost the same performance as the counter-only algorithm while preserving universal uniqueness of the generated ids.

To better measure the impact on performance, I created a small REST application that does not parse the query string and returns the response data directly, without going through @loopback/repository. Replacing uuid/v4 with hyperid improved the performance of my test application from ~2.4k requests/second to ~3.5k requests/second on average. The average request latency has improved from 3.8ms to 2.6ms.

The pull request loopback-next#5628 improving generateName performance has been already landed and will become publicly available in the next framework release.

Summary​

As the popular saying goes, performance is not a problem until it becomes a problem. Even if your project is not performance sensitive, it's still good to pay attention to how much resources it consumes at runtime.

1. Watch for warning signs. Maybe an existing test has suddenly started to fail on a timeout? When that happens, try to take the hard path: investigate the problem, dig deep to find the root cause and fix it.

2. Measure, measure, measure. Always create a reproducible benchmark to measure the effect of the changes you are going to make. Performance tuning is full of surprises and not all changes are for better.

3. Know the tooling. Node.js is compatible with many tools provided by Chrome's Developer Tools, it provides also tracing functionality for a more fine-grained analysis. You can learn more in Node.js documentation, starting from Debugging - Getting Started, Easy profiling for Node.js Applications and Flame Graphs.

4. Optimize hot paths. A semi-expensive function can become a performance problem when it's called for every incoming request.

Call to Action​

LoopBack's success depends on you. We appreciate your continuous support and engagement to make LoopBack even better and meaningful for your API creation experience. Here's how you can join us and help the project:

• Join the community Slack chat
• Report issues.
• Contribute code and documentation.
• Open a pull request on one of our "good first issues".