azureQuery vs. Azure SDK for Node

 

One of our recent projects involved using JavaScript to access Windows Azure data and features.  When considering the overall design, we discussed client- or server-side execution models (where the “meat” of the code will execute).  In this post we hope to expose what we learned in this process to others.  Although quite a few JavaScript libraries exist for accessing parts of Azure, the two we’ll analyze here are azureQuery and Azure SDK for Node.

First, a little context about each library:

azureQuery Azure SDK
Publisher David Pallman – Neudesic Windows Azure – Microsoft
URL azureQuery Windows Azure Node.js Developer Center
Code URL azureQuery on CodePlex azure-sdk-for-node on GitHub
Initial Release July, 2012 September, 2011

 

Next, some characteristics of the libraries:

azureQuery Azure SDK
Execution Locale Client-side (browser) Server-side (node)
Fluent (chaining) language support? Yes No
Storage Support?

Blob

Yes Yes

Queue

*Not Yet Yes

Table

*Not Yet Yes
Service Bus Support? ^No Yes
Identity & Access Control? No No
* As of 9/12/12, azureQuery only provides access to Windows Azure Blob Storage ^ We are not clear whether azureQuery plans to support Service Bus integration.

 

The table above highlights that, in its current state, azureQuery is very limited in its support of Azure features.  Actually, that’s to be expected. azureQuery was first published in late July, 2012; Azure SDK for Node was 10 months old at that point. We expect azureQuery will deliver support more areas of Azure, especially as the level of developer contribution improves (David Pallman has a full-time job, after all!).

 

Which should you use?

So, which of these libraries should you use for projects now?  If you’re thinking, “That’s not even the right question!” you are right!  Decisions regarding which code runs client-side or server-side has a great deal more to do with application requirements, scale expectations, data change rates, etc.

However, it is pretty clear at this point that azureQuery is still in its infancy.  If your goal is to rapidly deliver a solution using Windows Azure (beyond Blobs), then you should use Azure SDK for Node.  This decision will change as azureQuery fulfills its (assumed) mission. If solution demands client-side execution (e.g., rich visualization of changing data), then we encourage you to invest in azureQuery and contribute to its advancement.

How To Use Mocha for Node Testing in Windows

Even with some advice from other sites, we had trouble getting Mocha testing to work well in Windows.  Well, we could get tests to run, but inefficiently and error-prone from a developer perspective.  Our solutions are cross-platform, so we wanted to use a consistent mechanism for Windows and Linux (and assume Linux covers us well on Mac OS X).

Most of the suggestions from other sites worked, so we’ll just walk through them quickly.  But getting test execution via makefiles was a headache.  Aside: The “Unix Way” uses makefiles for almost everything.  The Unix Way for a developer to execute Mocha tests is to simply type ‘make test‘  Without getting into any philosophical or pragmatic rationales, this is the best way we’ve found for cross-platform Mocha testing.

Setting Up Your Environment

We’ll assume that you already have Node configured and working.  The first step is to get Mocha installed and configured. As with most Node packages, installing Mocha is as easy as

npm install mocha

Once installed, Mocha shows up in the list of packages

Mocha in Node Packages List

Now you’re ready to create tests.  Just follow the instructions, 1. 2. 3. Mocha!, on Mocha’s GitHub site.  Their instructions are written for a Unix-like environment (.e.g., “$EDITOR test/test.js”), but translation is simply:

  1. Create a test directory
  2. Use your favorite editor to copy the provided JavaScript in to test\test.js file
  3. Run Mocha

Oops! Step 3 doesn’t work on Windows like they expect it will on Linux.  Yes, you could add Mocha to PATH, but that’s not the better solution – especially since we aim to use make to run the tests.  So we’ll just skip step 3 and get help from Alex Young’s excellent post, Testing With Mocha.  You can skip the first bit about creating a package.json file and using npm to install Mocha.  (Eventually you’re going to want to leverage the power of the Node Package Manager!)

Just copy Alex’s simple, 3-line makefile to your directory (the parent of the test directory where you stored test.js).   If you were using a “typical” unix developer environment, you could simply run the tests in test.js by using make:

make test

In most Windows developer environments, however, makeeither doesn’t exist or isn’t going to work correctly.  Other have written, for example, that Visual Studio’s nmake.exe isn’t a good proxy for make in this case.  As you search for how to remedy this situation, you’re likely to come across Mocha requires make. Can’t find a make.exe that works on Windows on StackOverflow.com. The elements of this post that proved to be helpful are:

  1. Install Cygwin
  2. Alias make to Cygwin’s make.exe ([install location]\cygwin\bin\make.exe)
  3. (Optional) Use the makefile template from Richard Turner’s response

Now you should be able to make test and see the test run, right?  Well, not so fast professor.  Cygwin’s make.exe conforms to some White Space Persnicketiness Specification.  We thought surely we were ready to execute our tests, but kept suffering make errors about “missing separator.”

Make missing separator errors

Well, sir, that’s what we call a helpless error.  It’s an error alright, but sure isn’t helpful.  It turns out, however, that had we been steeped in unix-land makefiles, we might know that white space matters.  That is to say that make treats a series of spaces differently than tabs.  If your favorite editor is converting tabs to spaces, then make complains of “missing separator.”  [UPDATE: some have suggested that GNU’s Make for Windows handles tabs or spaces.]

Ok, we’re almost there.  You’ll need to configure your editor to keep tabs rather than convert them to spaces.  Ideally, your editor will also support writing files with unix-style line endings, LF (\n) rather than CRLF (\r\n) typically used on Windows.  Below is an example of how to configure Notepad++.

Notepad++ Configuration to Keep Make Happy

Since make doesn’t like tabs to be converted to spaces, we change our Notepad++ settings to save the tabs rather than convert them.  Visual Studio and other developer-oriented text editors have similar settings.  In Notepad++ select Preferences from the Settings menu, and then the dialog tab for Language Menu/Tab Settings. Select Makefile in the Tab Settings, listbox on the right; turn Use default value and Replace by space off.  After you save these settings, you’ll also need to replace the spaces in your makefile with tabs.  For example, we replaced the beginning spaces on Line 2 below with a beginning tab.  Just save your changes, and you should be able to make test successfully.

Notepad++ Makefile Tab Settings
If you’re also interested to configure Notepad++ to use unix-style line endings, select Unix Format from the EOL Conversion menu item of the Edit menu.

Notepad++ End of Line Configuration

 

Whew! That wraps it up.  Now your developers should be able to use make test in Windows, Linux and Mac environments.  One less difference to remember between platforms means one more boost to developer productivity.

We hope this is helpful to you.  Feel free to leave comments if this works for you, if it doesn’t, etc.