One of the great things about Azure Mobile Services (WAMS) is the fact that not only is it built on Node.js but also that it allows you to fully leverage the power of the platform, specifically though the use of custom Node.js packages downloaded from NPM along with custom packages developed locally.
To allow this interaction to occur it is necessary to enable the Git for your Azure Mobile Service. Doing this is easy, after you create a service, go to the Dashboard and click the link indicated below:
This process can take a while, but when it is complete you will be taken to the ‘Configure’ tab of your Mobile Service. You will see a section titled ‘Source Control’ which will provide you with a Git URL which will be the location for your remote. Note: A full discussion of Git is beyond the scope of this article, I recommend this for reading: http://git-scm.com/
Once you do your ‘Pull’ of the code at this URL you will notice a the following directory structure:
- service
- api
- scheduler
- shared
- tables
As you might expect, each folder maps to a specific WAMS feature that supports code being written against it.
In Node.js the require function is used to load an external modules (like those downloaded from NPM) and allow their usage in scripts. The require function, when called, recurses upward looking for directories called node_modules as a location to search for the desired code module. This is important to understand as it can simplify your calls an enable you to isolate certain modules.
Note: I have read that the ‘Shared’ folder is the recommended spot to put shared code (ie modules) in WAMS. I do not agree with this since it undermines the use of require and creates a weird path to be used in the application. In this case, I differ to Node.js standards over Microsoft.
So, from within the service folder, run npm install (command line) and install your favorite package. After completion you should notice a new directory created called node_modules within which is the source of your module. We won’t be talking about the structure of Node.js modules in this post, but I encourage you to read up on them as modularizing code, especially with JavaScript, is a great way to enhance reusability and reduce the code you write.
Realize, that all you just did was add files to your local Git repository and these files can be pushed like another files you would add (appropriate commands pending). Once you push the code up to WAMS it can be used by your scripts. This enables you to use Node.js on WAMS as you would with any other Node.js application.
Here is an example, from a current application, of how a Node.js module loaded this way can be used:
function LoadScores() { var request = require("request"); request({ url: "http://www.foo.bar", json: true }, function(error, response, body) { if (!error && response.statusCode == 200) { var objectArray = body.trimResponse().parseResults().toGameArray(); // prepare to read from the games table for (var i=0; i<objectArray.length; i++) { var game = objectArray[i]; insUpGame(game); } } }); }
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
Here the request module is used to make a GET request for JSON data which is then stored in a database within Azure. The use of a module here reduces the amount of custom code that is needed for the operation.
I have found that many people are surprised to find that Microsoft choose to use Node.js as the backing technology for WAMS over something IIS; I am not. The reason is that Node.js lends itself to the type of configuration model that WAMS uses in allowing point and click declaration of endpoints and tables, much easier to handle the routing. But more than that, Node.js is an established platform for data intensive applications (used heavily by LinkedIn and Groupon, among others) and given that WAMS intends to allow developers to create a common backend for connected applications the ability to work with and handle data is a given. In my opinion, the deeper integration with Node and the ability to fully leverage the platform give WAMS more long term potential than something like Parse.