Azure Mobile Apps and NodeJS

Microsoft has just open sourced the Azure Mobile Apps SDK for Node. One of the promises of Azure App Service was the ability to throw together apps that serve the web and mobile community simultaneously and to do it quickly. This capability has been available with the .NET crowd for a while. With the release of the Azure mobile Apps SDK for Node, it’s available to Node programmers too.

The SDK is built on top of ExpressJS – a very well-known and respected web service. This means you can develop your web application using all the power of the ExpressJS platform, then add the Mobile Apps piece. I’m writing a Single page application, so my entire app is in a static area. Let’s take a look pre-Mobile Apps work (written in ES6):

/// A basic web server based on ExpressJS that serves up static content

import express from 'express';
import http from 'http';
import morgan from 'morgan';
import staticFiles from 'serve-static';
import {extractAuthSettings} from './utils';

var service = express();
// HTTP Port is set by PORT in Azure
var httpPort = process.env.PORT || 3000;

// Morgan is a logging service -
// NODE_ENV === 'production' on Azure
if (!process.env.NODE_ENV || process.env.NODE_ENV === 'development') {

// Serve up files from a static area - we are a SPA

service.get('/api/settings', (req, res) => {
  try {
    let settings = {
      auth: extractAuthSettings()

    res.set('Content-Type', 'application/json');

  } catch (err) {
    // If there was an error, then return 404

// This code actually listens on the specified port.  Uses the PORT
// environment variable to determine the TCP port to listen on.
http.createServer(service).listen(httpPort, err => {
  if (err) {
    console.error(`Error listening to port ${httpPort}: ${err.code}`);
  } else {`Listening on port ${httpPort}`);

This code does two things for me – first, it serves up the contents of ./wwwroot as static files. I have a whole build process for handling this, since my application is ES6, React and Flux based. I’ve also got a single API called /api/settings that returns any settings I need. Since I store my authentication settings in the App Settings section of Azure (and environment variables when I’m developing locally), I have a function for creating the object.

Now, let’s add an API for serving up database tables. We’ll use the Azure Mobile Apps SDK for Node for this. First off, load up the API:

npm install --save Azure/azure-mobile-apps-node

Yes, it’s so new it doesn’t have an npm entry yet. That will come in due course. The SDK is only in preview right now, so it could materially change before release.

Now that I have the SDK installed in my project, the code needed to add a simple table controller is just four lines. At the top of the file, I import the SDK:

import express from 'express';
import http from 'http';
import morgan from 'morgan';
import staticFiles from 'serve-static';
import {extractAuthSettings} from './utils';
import azureMobileApp from 'azure-mobile-apps';

Right before I start listening for connections, I do the following:

// Create a new Azure Mobile App
var mobileApp = azureMobileApp();

// Define the tables we are going to expose

// Attach the app to the Express instance

This provides a simple API on /tables/GWCharacters. You can get the table which will return a list of all the entries, plus you get individual record CRUD operations:

  • C = Create = POST a new entry
  • R = Retrieve = GET an ID
  • U = Update = PATCH an existing entry
  • D = Delete = DELETE an existing entry

These operations are designed to be mobile offline-sync friendly. That means you can use one of the client SDKs for Azure Mobile Apps and utilize this same API.


By default the SDK uses the Azure SQL Database. It will pick up on the appropriate Connection String when you create the Azure SQL Database – I’ve blogged about that before. However, during development you will likely want to use a local database. Even though Visual Studio comes with SQL Express, it’s generally best to install from the install media so that you can get access to the SQL Server tools like Configuration Manager. This will ease your administrative burden in getting it set up. You can download the SQL Server 2014 Express Edition from Microsoft. Make sure you download SQL Server 2014 Express with Tools.

If you are going to be testing and developing by deploying to Azure, then you don’t need to do this.

Once installed, you will want to configure the following:

  1. TCP Port Enabled
  2. A new database
  3. Username and Password for access

These pieces will also be used to formulate the Connection String I need for the local version of the database. Once you have the SQL Server 2014 Express installed, start SQL Server Configuration Manager. Expand the SQL Server Network Configuration and then double-click on the Protocols for SQLEXPRESS:


Right click on the TCP/IP and select Properties, then select the IP Addresses tab:


For each entry, set the TCP Port to 1433. If you don’t want to set them all, then make sure you set the entry for and IPAll. Once this is done, click on OK. Then right-click on the TCP/IP protocol again and select Enable. It will prompt you to say that you need to restart the service. To do this, select SQL Server Services in the left hand tree. Highlight the SQL Server. Right-click and select Restart.

The new user and database are handled in a different tool – the SQL Server Management Studio. Connect to the local instance (it’s the default connection most of the time). Right-click on Databases and select New Database.... Enter a name (mine is grumpy-wizards), then click on OK.

To create a username and password, expand Security, then Logins – you will note that a bunch of logins are created by default. Right-click on the Logins node and select New Login.... Enter a suitable login name (I used gw_access), select SQL Server Authentication and enter a password. It’s a good idea to uncheck the User must change password at next login and Enforce password expiration boxes – this is a test scenario, after all. Select the database you created as the default database. Then click on OK.

This doesn’t provide the user with access to the grumpy-wizards database. Right-click on the login ID (in the Security -> Logins node) and select Properties. Go into the User Mapping area and map the grumpy-wizards database. Select dbo as the Default Schema and ensure the user has db_owner and db_datawriter role membership checked:


You need the ability to create tables within the database. Under normal circumstances, you would use fine grained controls, granting the CREATE TABLE and ALTER SCHEMA permissions only within grumpy-wizards. However, this is a test database – not the production database. I generally give more permissions in development.

A final piece needs to be done. Right click on the server and select Properties, then Security. Under Server Authentication, check that the mode is SQL Server and Windows Authentication mode. If you don’t have this selected, then your user won’t be able to log in. If you change it, click on OK, then right-click on the server again and select Restart.

Once all this is done, you can construct a connection string for test purposes. Here is mine:

$env:SQLCONNSTR_MS_TableConnectionString = "Data Source=; Database=grumpy-wizards; User Id=gw_access; Password=YourPassword; MultipleActiveResultSets=true;"

Phew! Fortunately, this is a one time activity for your app. For testing, I recommend downloading Postman – you can send the URI localhost:3000/tables/GWCharacters:


This is the GET ALL RECORDS request. We currently don’t have any responses. Let’s do a POST of some new data:


When sending the body, change the application type to JSON (application/json). If you don’t, the table controller won’t realize it has to decode the text before applying it to the database. It will create the record but without content.

I can now GET localhost:3000/tables/GWCharacters/e094bf05-ea52-484d-b5f5-c25542e00562 to get the record details. This URI is based on the id of the record. Also note the fields with a double-underscore – these are added by the SDK to support Offline Sync and Soft Delete. If you flip over to the Headers, you will notice an ETag. This allows you to implement caching and only returning entries that have changed.

This isn’t ideal. There are a number of things I want to do here. Firstly, GWCharacters isn’t the only table I want to produce. Adding additional tables is trivial – just add more tables to the mobileApp variable. I also want to define the acceptable fields in configuration and link in authentication by utilizing the social authentication from the client that I have already implemented.

However, first pass – I have a Mobile API that I can use from my client code. You can download the Azure Mobile Apps SDK from their GitHub repository.