Microsoft Azure's DocumentDB is a great PaaS NoSQL database. The killer feature is that you can write stored procedures in JavaScript (CoffeeScript in my case) AND the operations performed in a single run of the stored procedure is contained in an ACID-compliant transaction -- even if the transaction effects more than one document. This means that either all operations are completed or none are and that none of the operations of an incomplete transaction are seen by any other database interaction. Also, to quote VoltDB (similar in design to DoucumentDB except stored procedures are written in Java), "Code is smaller than data. Move the code to the data." In DocumentDB, the JavaScript is run in the same memory space as the database which provide performance advantages. I will publish my performance findings confirming this shortly.

I use the Node.js client on occasion for inspection or testing, but, knowing the advantages of using stored procedures, I have adopted a pattern of doing all database operations for production code inside of stored procedures.

However, the infrastructure around DocumentDB is not yet mature. A particularly painful aspect of this is that it's missing a good way to test and debug your stored procedures. Sure, you can attach execution state to the "body" that is returned from the run to see what's going on, but it would be much easier if you could use your local debugger and write automated tests to confirm the functionality before you pushed your stored procedure to the server.

Luckily, stored procedures are just JavaScript so we can use Node.js to test and debug them. This documentdb-mock package implements a thin mock to enable this testing and debugging.

So, you can find it on npm at https://www.npmjs.com/package/documentdb-mock or GitHub at https://github.com/lmaccherone/documentdb-mock.

As always I appreciate input and pull requests.