Announcing LoopBack.next, the Next Step to Make LoopBack Effortlessly Extensible

History

In 2013, we started LoopBack as a mobile-backend-as-a-service, evolving out of earlier efforts such as Deployd and JugglingDB. Users quickly told us that what they needed wasn’t a backend-as-a-service itself, but a framework to build their own MBaaS. We built LoopBack on top of the popular Express library and based it on open standards to ensure compatibility; We developed it in the open to ensure we could address users’ problems and needs.

Powered by LoopBack

What’s Next?

The core LoopBack team has talked to thousands of people about LoopBack over the past three and a half years. These discussions have molded our thinking about what users need and how to proceed. Read more

An Example of Using Environment Configuration in LoopBack

One of the more interesting features of LoopBack I’ve been meaning to take a look at is its support for “environment configuration”. This is a fancy way of saying “configuration based on environment.” I’m still a Node newbie, but this is something I’ve done myself for a while now. Once again, LoopBack really shines here in doing some of the boilerplate code for us. The docs go into great detail about this feature, but I thought a simple example might be useful.

First, a reminder. LoopBack uses JSON files for various different configuration settings. In every case where there’s a JSON file, you can swap it out with a regular JavaScript file to enable dynamic configuration instead. So for example, datasources.json can also be datasources.local.js. (Note – in this case, “local” isn’t referring to any environment. The requirement for the word “local” in the file may go away soon.) This allows you to define the same values the JSON file does – but with JavaScript code. This could be useful for dynamically creating a datasource at run time. (This could lead to some fancy scenarios – so for example, trying to connect to a main database and if that fails, use a backup.) Read more

Webinar: LoopBack, MongoDB, and Continuous Integration

Considering using LoopBack to create an API for your data in MongoDB? Then mark your calendars! We have a new webinar coming up on Tuesday March 28th – “LoopBack, MongoDB, and Continuous Integration”.

LoopBack is a great tool for quickly generating a CRUD API for your data stored in MongoDB. In this webinar, we will walk through setting up a continuous integration pipeline with tests, and show a few different deployment options.

loopback-logo-sm

Erin McKean (Lead Developer Evangelist, IBM Cloud) is the webinar speaker and will provide a comprehensive walkthrough of a full MongoDB-backed API, including unit tests, continuous integration, and deployment examples.

When: March 28, 2017
Virtual door opens at 12:45 pm EST
Webcast starts at 1:00 pm EST

Register Now!

Also, don’t forget about the webinar we announced last week – Combining OpenWhisk (serverless), OpenAPI (swagger) and API Connect to Build Powerful APIs.

Webinar: Combining OpenWhisk (serverless), OpenAPI (swagger) and API Connect to Build Powerful APIs

Our next webinar will be held on March 16th, focusing on “Combining OpenWhisk (serverless), OpenAPI (swagger) and API Connect to build powerful APIs”.

Using the power and simplicity of serverless functions and exposing them via API Connect provides a clean and organized way to build powerful APIs, applications and integrations for your developer and your customers. We will go over both technologies, as well as OpenAPI, to see how the magic comes together.

Read more

Context Propagation in LoopBack

LoopBack developers often need to propagate information (aka “context”) from the HTTP layer all the way down to data source connectors. We hear this regularly in the LoopBack discussion forums and GitHub issues.

Consider the following examples:

  • When querying a database for a list of “todo” items, return only the items owned by the currently logged-in user.
  • When making a REST or SOAP request to a backend service, include a transaction/correlation ID from the incoming HTTP request headers in the outgoing HTTP request headers, so that these two requests can be linked together by logging and tracing tools.
  • When formatting an error message, translate it to the language understood by the user, as indicated by the HTTP request header “Accept-Language”.

These examples share a common pattern: the app needs to access information in the layer handling incoming HTTP requests, but it is not included in the arguments (parameters) of remote method APIs.
Read more