Introduction to API Connect for LoopBack Developers

If you’re a LoopBack developer, you have no doubt heard about IBM API Connect, the first product to come out of the IBM acquisition of StrongLoop.  You may not have paid too much attention to it yet, perhaps thinking it’s not relevant to you, or perhaps you’re happy enough using LoopBack and the StrongLoop tools. This blog provides a gentle introduction to API Connect for current LoopBack developers, as well as some good reasons why you may want to consider switching from StrongLoop to the API Connect tools.

Read more

Announcing Transaction Tracing for Node.js Beta

At StrongLoop, we develop tools to support development and operations throughout the entire lifecycle of API development. Initially, we released Arc Profiler to help you understand performance characteristics of your Node application. Next, we added Arc Metrics to provide real-time visibility into your staging and production environments. Today we’re announcing the latest Arc module, Tracing, (currently in public Beta) that enables you to perform root cause analysis and triage incidents in production. (You can watch a short overview and demo of the Tracing module here.)

Those who have cut their teeth on the seemingly endless iterations in the dev lifecycle  will understand this satirical spin on Dorothy’s line from the Wizard of Oz:

“Toto, I don’t think we’re in staging anymore…  There’s no place like production… There’s no place like production…”

Simulated load, automated testing, and all the CI magic in the world won’t prepare you for the “gotchas” that can happen in production.  If you’re lucky, you’ll have a canary that keels over as soon as you enter the production mine.  But what then?

The answer is Tracing.  The Arc Tracing module provides the ability to call in the artillery when you need it.  If you see something of interest in Metrics, open up Tracing and you’ll be shown a timeline of memory and CPU usage.

Understanding the Timeline

tracing21

Locate the point of interest—more often than not a CPU or memory spike in the form of a peak in the line—and start to drill down. When you’ve located the incident, you’ll want to freeze the time slice by clicking on the chart drawing your black line denoting a time slice and starting your drill down.

Read more

StrongLoop Node.js Tracing Quickstart

We recently added the Tracing module (currently in Beta) to StrongLoop Arc’s monitoring and performance analysis tools. Tracing helps you identify performance and execution patterns of Node applications, discover bottlenecks, and trace code execution paths. This enables you to monitor Node.js applications and provides tracing data at the system and function level, giving you insights into how your application performs over time. Tracing works with applications deployed to StrongLoop Process Manager (PM).

This blog post describes how to quickly get up and running with Tracing, assuming you have  some familiarity with StrongLoop tools. It demonstrates the quickest path to try out the new Tracing module, using an example that simulates some load, and how to view and understand the data visualizations based on your application traffic.

Step 1. Setup

Start by installing the latest version of StrongLoop and creating a basic Loopback application. If you have never done this previously, please refer to: http://loopback.io/getting-started/

Clone the example app from https://github.com/strongloop/tracing-example-app and go through the set up:

This example demonstrates the tracing in of StrongLoop Arc. The example includes a simple HTTP server with one route that starts an internal busy loop when triggered.  This generates fluctuations (and thus more data) for the StrongLoop Arc tracing graphs.

Please review the README to get your example app up and running and create some variation in the graphs by running the ./send-request script to make repeated curl requests to the server.

Read more

Node.js Transaction Tracing Deep-Dive By Example

StrongLoop recently announced a public beta of a Node.js transaction tracing module (read the announcement blog or watch the overview and demo video) within StrongLoop Arc to identify performance bottlenecks. In this blog we walk you through a sample application and insights into the patterns that emerge while conducting a Node.js transaction trace.

How Tracing works

StrongLoop tracing monitors your Node application by:

  • Tracing JavaScript functions entry and exit points to record the elapsed time of each function call and the position of the function call in the source file. Tracing instruments every function in your application as well as the packages your application requires.
  • Wrapping all HTTP and HTTPS requests and database operations of MySQL, PostgreSQL, Oracle, Redis, MongoDB, and Memcache/Memcached.

 

A DoS use case

In this blog, we’re going to analyze behavior of a simple application that implements one Oracle database transaction responding to GET / HTTP request. We’ll consider a hypothetical scenario in which your website gets a denial-of-service (DoS) attack that generates unusual CPU load.

We’ll use an example and demonstrate how to analyze the tracing data and drill down to the specific source code line of the vulnerability exploited by the simulated DoS attack.

tracing1

Read more

Use LoopBack’s Geolocation Feature to Build a Simple Node.js User Registration App

If you’ve been looking for a framework to help you get your REST APIs up and running quickly, with a robust set of functionality and flexibility, then the LoopBack Framework is what you want. This framework helps developers create APIs that integrate with legacy systems, Cloud APIs, while enabling micro service architectures, mobile services, and much more. A lot of this functionality can be easily managed either with the slc command line tools or the visual tool called StrongLoop Arc.

In this post, I’ll show you how to build a simple self registration application using the Loopback framework with authentication and geolocation capabilities built-in. The application utilizes the following features of the LoopBack framework:

  • Authentication
  • Geolocation support
  • MongoDB connector
  • AngularJS SDK

The finished example application can be found on GitHub.

Prerequisites

The Self Registration API

The REST API for this application provides user creation, user authentication, ability for the user to save preferences (i.e… street address), and backend Geolocation functionality to get the weather for the street address specified by the user.

I decided to create a model called Subscriber. For this, I take advantage of how easy the LoopBack Model Generator. This model will extend the built-in User model. Since the User model is based on the PersistedModel, our Subscriber model will be filled with all the REST CRUD goodies for free.

I added two properties to the Subscriber model:

  • preferences: This property is of type object, which means we can store embedded properties. We store the street, city, zipcode, and temperature properties.
  • geo: This property is of type geopoint. We store the latitude and longitude corresponding to the address stored in the preferences property.

Steps for Creating the Application

Now, we’ll create our application using the slc loopback application generator.

Install the following supporting Node modules:

These modules are used directly and indirectly within the code and/or the LoopBack Framework. The loopback-connector-mongodb Data module is used internally by the LoopBack Framework to provide access to the MongoDB database. The loopback-connector-rest Integration module is used internally by the LoopBack Framework to provide access to existing system that expose APIs through common enterprise and web interfaces. Further information on LoopBack connectors can be found in the documentation.

The function-rate-limit module is used by the sample to code due to a limit of requests per second imposed by the Google Maps API. You’ll find the use of this module in the loopkupGeo function expression in the common/modules/Subscriber.js file.

Creating the Backend DataSource Definition

Assuming the MongoDB server is installed and up and running, let’s configure the mongoDBDs datasource. We are going to use the previously installed loopback-connector-mongodb connector. Once again using the extremely useful slc from the command line we’ll tell slc that we want to create a new datasource.

Edit the file server/datasource.json file to update the mongoDBDs entry to look like the snippet below. Of course, you’ll want to use whatever credentials you need for your actual MongoDB datasource!

Creating the REST Connectors Definition

It’s time to create our REST connector definitions. Let’s configure the Google GeoCode API Rest Connector:

Edit the server/datasources.json file again and update the geo data source entry to look like this:

Now we need to configure the OpenWeather API Rest Connector:

Edit the server/datasources.json file once more and update the openweathermap datasource entry to look like this:

Creating the Subscriber Model

There are different way to create models. The easiest way is using the module generator tool. This tool will prompt you for information about the type of module you want to create, persistence type, properties, among other things, and generate javascript and json files corresponding to your model. For further information about creating modules can be found in this section of the documentation.

We need to create a Subscriber model with the following characteristics and properties:

  • The model will extend the built-in User model.
  • A property named ‘preferences’ of type ‘object’. We used the type object so we have the flexibility to add json attributes within this property.
  • A property named ‘geo’ of type geopoint. We use the geopoint to store latitude and longitude values.
  • Attach the model to the data-source ‘mongoDBDs’.
  • We do want to expose as a REST API.

The following steps show you how to the create the Subscriber model:

The tool generates the following files: subscriber.js and subscriber.json. These files can found in the /common/models directory. The subscriber.js javascript file is where all our logic will reside. The subcriber.json file contains information about the model name, properties, validation, relations, acl, etc…

Extending the API

The LoopBack Framework provides the standard CRUD REST operations for the models. We need to extend the API to intercept the save calls for the Subscriber model as well as a remote method to get the weather data corresponding to the address stored in the preferences property.

When the Subscriber preferences are saved we intercept the street, city, and zipcode right before they’re saved and perform a lookup using the LoopBack REST connector to access the Google Geocode API. This API will provide us with the latitude and longitude for that address. The latitude and longitude will be stored in the ‘geo’ property.

To accomplish this we use a Remote Hook. A remote hook is simply a function that gets executed before or after a remote method or endpoint. We use the beforeRemote(), which runs before the operation we would like to hook on. For example:

The ‘prototype.updateAttributes’ action gets called when the Subscriber object is saved. In our remote hook we perform the geo lookup before the object is saved.

The lookupGeo function will perform an http request using the Google’s Geocode API. We’re using the ‘function-rate-limit’ module here to overcome the 10 requests per second imposed by the API.

Next, we added a Remote Method to ‘getWeather’. Basically, this remote method is used to extend the standard REST CRUD methods and the model’s behavior.

The Subscriber.getWeather function is used to extend the Subscriber’s REST API to add remote method that will allows to get the weather for the previously stored Geolocation.

Security Changes for the API

Since we only want to get the weather for the authenticated user, we need to add an ACL
for the remote method. An ACL is an access control list used by LoopBack to enforce restrictions to data provided by models. The ACL indicates what type of authority is needed to access CRUD operations or Remote methods of the models. For more information, see Controlling data access.

Once again the slc tool is used to create an ACL to the Subscriber.getWeather remote method. We use the following criteria for the ACL:

  • Subscriber model
  • Single method ACL scope
  • Applied to the method ‘getWeather’
  • The user owning the object
  • Explicit grant access
Finally, we need to stop exposing the built-in User model. By default the User model will be created and expose thru the REST API. Since we don’t use this model from the client, we’ll just disable it by adding the property “public”: false to the model in the server/model-config.json file:

Create the AngularJS Client

Another cool feature of the LoopBack framework is the AngularJS SDK. It provides facilities to generate $resource services corresponding to the REST API we
generated from the models. The following steps would take care of generating the AngularJS services.

The lb-ng tool generated the app/client/app/services/lb-services.js. This file contains the Angular services corresponding to Subscriber REST CRUD API, plus remote method getWeather. The service will be proxied by the selfRegistrationLoopBackApi service. The idea behind this service is to shield the rest of the application of the low level REST calls to the backend. There are two controllers HomeCtrl and PreferencesCtrl. These controllers communicate with the selfRegistrationLoopBackApi to perform all the required functions like Authentication, getWeather, savePreferences.

The typical flow for user would be:

  • First time the user would signup or login if an account already exists.
  • The user can change the preferences (Address) in the preferences page.
  • In the landing page, the code will determine if the needs to get the weather for the authenticated user.

The following diagram depicts the design/architecture of the sample application:

lb1

That’s it! If you curious to see how the rest of the AngularJS side was built, take a look at the finished application here on GitHub.

Here is a video demonstrating how the application works:

lb2

Conclusion

As you can see it’s quite easy to get an application up and running with the LoopBack Framework. The framework documentation is excellent, updated frequently, and the Getting Started with LoopBack and Getting Started II tutorials are great resources to learn about the built-in features.

You can find the code for this example on Github.