Introducing azureQuery: the JavaScript-Windows Azure Bridge

As anyone who follows this blog knows, my twin passions are Windows Azure and modern web development and I especially like combining the two. In this post I introduce a new project-in-the-works called azureQuery, whose purpose is to provide a first-class way for client-side JavaScript to get at Windows Azure. Before going any further, check out a few azureQuery statements to get a feel for it:

// Get a list of containers
var containerList = aq.storage().containers().containerCollection;

// Get a list of blobs
var blobList = aq.storage.container('orders').blobs().blobCollection;

// Store a JavaScript object in a blob
var order = { ... };
aq.storage().container('order').blob('order-1001').json(order);

//  Retrieve a JavaScript object from a blob
var order = aq.storage().container('order').blob('order-1001').json();

// Process each XML blob in a container
aq.storage().container('test').blobs('*.xml').each(function (blob) {
    ... work on blob ...
});

Why azureQuery?

One reason we're developing azureQuery is to give client-side JavaScript easy access to Windows Azure. Microsoft already does a good job of making it possible to get at Windows Azure from a variety of developer environments: if you visit the Windows Azure Developer Center, you'll see there are developer centers for .NET, node.js, Java, PHP, and Python. However, there's nothing for client-side JavaScript. Modern web developers know that a large part of our applications are moving over to the web client side and the role of JavaScript has been elevated: it's no longer just "web glue" but where much of our code lives. So that is one reason for azureQuery, to provide a JavaScript API for web developers.

Another reason for azureQuery is to provide a jQuery-like chaining API. I find jQuery to be simply brilliant, a powerfully-designed API for doing lots of powerful things with elegance and brevity. jQuery is a big inspiration on what we're trying to achieve with azureQuery. Like jQuery, azureQuery has the ability to perform operations on whole sets of things using selectors. Like jQuery, azureQuery is a fluent (chaining) API.

Good JavaScript object support is a key objective in azureQuery. In the blob storage functionality that has already been implemented, you can easily store and retrieve JSON objects to blob storage. We plan to do the same with table storage.


How azureQuery Works

On the web client, azureQuery providea a JavaScript Singleton object named aq using the JavaScript Revealing Module pattern. JavaScript developers invoke functions off of the base aq object to interact with Windows Azure. The library interacts with a server-side service to perform its work.

<script src="~/Scripts/azureQuery.js"></script>
...
var blobsList = aq.storage().container('docs').blobs('*.doc').blobCollection;

On the web server, azureQuery has a matching ASP.NET Web API service that uses the Windows Azure .NET APIs. RESTful URIs are issues to instruct the server.

/api/blob/blobs/?c=docs&b=*.doc&d=true

In an ideal world, this server-side component wouldn't be necessary: you'd just take azureQuery.js and go to town, interacting with Windows Azure's services directly. Alas, Ajax communication from a browser has cross-domain restrictions. This means you have to run some server code to make azureQuery work. The projects you can download from http://azurequery.codeplex.com include both the client-side JavaScript library and an ASP.NET Web API service for the server. It' s possible we'll get around this at some point using JSONP, but for today it is necessary to host a server-side Web API service to make azureQuery work.


Roadmap

The intention with azureQuery is to incrementally build out different functional areas over time.

The first area we're implemented is blob storage, available right now in the azureQuery 0.1 release. You can access containers and blobs, with wildcarding. Operations you can perform on containers and blobs include list, create, copy, and delete. You can store and retrieve blobs as text, byte arrays, or JSON objects.

Next up on the roadmap is table storage, which will appear in the upcoming azureQuery 0.2 release.

Eventually, we plan to include many other functional areas including the management capabilities available in the Windows Azure portal.

We'll be covering each individual area of azureQuery as it comes into being in the successive articles in this series.

You can read about and download azureQuery here. azureQuery is a community donation of Neudesic.


Feedback Appreciated, But Please Be Careful

If you play around with azureQuery in this early stage, be careful. It's new code, so you might be the first to exercise a particular area. It has a lot of power--for example, you could wipe out all your blobs and containers with a single statement:

// delete all blobs and containers
aq.storage().containers().blobs().remove();

azureQuery is also not yet equipped with an out-of-the-box security model, so it's up to you to secure it if you use it at this early juncture.

We'd love to hear feedback as we continue to develop azureQuery, but please be careful in your use of it. We suggest starting out with local Windows Azure Storage Emulator storage, data you can afford to lose.

Stay tuned for more in the series as we go into each functional area of azureQuery.