Azure Demo: A Quick Intro to Azure DocumentDB's Server-Side Javascript

[Microsoft Azure] [Azure DocumentDB] [Server-Side Javascript] [male speaker] Hey there, my name is Andrew Liu, and today I'm going to show you one of my favorite Azure DocumentDB features. Let's talk about bringing full stack JavaScript into the database. DocumentDB's server-side programming model allows you to write integrative JavaScript logic to be shipped and executed directly on the database itself. This is expressed in the form of stored procedures, triggers, and user-defined functions. I have found this particularly useful for performing complex sequences of operations closer to your data. In other words, you can write high-performance batching and sequencing operations without the need for multiple network requests. Wait, it gets even better. [ACID Transactions across multiple documents!] DocumentDB guarantees that database operations performed inside a single store procedure or trigger are atomic. That's right—you get fully ACID-compliant transactions across multiple documents inside a collection. Simply put operations made with in-store procedures and triggers, either all succeed or none succeed. Awesome. So how would you do this? For this video, I will use the DocumentDB Node.js SDK with Q promises to interact with my database using stored procedures. Let's take a look at this Hello World stored procedure. Check it out. It's plain JavaScript. There are no crazy new semantics to learn. Now, everything begins with a context object, which provides access to all operations that can be performed on the DocumentDB collection, as well as access to the request and response objects. This context object can be retrieved via the getContext method. In this example, we placed the string HelloWorld into the response, which will get passed back to the application. Now that we've defined our stored procedure, how do we use it? Let's register the stored procedure onto one of our database collections. This is accomplished via the document client's create stored procedure async method, which takes two parameters— a reference to the collection and the stored procedure we just defined. Once the stored procedure is registered, we can execute it against the collection and read the results back at the client. This is accomplished via the document client's execute stored procedure async method, which takes in a reference to the stored procedure as a parameter. Now let's take a look at a slightly more interesting example. Let's say we have a game with two players, Ralph and Heather. Ralph is a level 40 warrior and has an iron sword. Heather is a level 40 druid and has a diamond pick axe. Ralph would like to trade his iron sword for Heather's diamond pick axe. Recall that stored procedures are for atomic transactions in which all work done will be treated as a single unit. Either all of the work is committed, or none at all. Stored procedures ensure consistency, isolation, and durability. With multi-document transactions, we don't have to worry about the player data getting into some corrupted state. In other words, we're safeguarded from having both players ending up with the same item or losing any player data. Here we have a stored procedure that uses transactions to trade items between two players in a single operation. In this example, the stored procedure receives two player IDs passed in as arguments. The stored procedure will attempt to read the corresponding player documents. If both player documents are found, then the stored procedure updates the documents by swapping their items. If any errors are encountered along the way— if there was a JavaScript exception that implicitly aborts the transaction so that no work will be committed. Now, here are some things to notice. All operations are asynchronous and depend on JavaScript function callbacks. The callback function has two parameters— one for the error object in case the operation fails, and one for the created object. Inside the callback, users can either handle the exception or throw an error. It is also important to note that server side JavaScript have bounded execution time. All operations contained in stored procedures must complete within the server-specified timeout duration. If an operation does not complete within that time limit, the transaction is rolled back. Otherwise, if the stored procedure completes in time successfully, the transaction is committed. In order to simplify development to handle these time limits, all functions under the collection object return a Boolean value that represent whether the operation will complete. If this value is false, it is an indication that the time limit is about to expire and that the procedure must wrap up execution. In this simple example, we will throw an exception to roll back the transaction. For other scripts, you may choose to implement a continuation-based model by gracefully returning and completing execution. Let's use a bulk import script as an example. You can check the Boolean return value after creating a document, and if false, return the countif documents and asserted to track and resume progress across import batches. After we have run the stored procedure, we can see that the players have swapped items. Ralph now has Heather's diamond pick axe, and Heather now has Ralph's iron sword. You have just seen a glimpse of DocumentDB's server-side programming model. To learn more about DocumentDB, check out their website at DocumentDB.com. Also, please feel free to email me if you need any help, want to express feedback, or would like any questions answered. I'm extremely passionate for this service, and am more than happy to help you in any way I can. Have fun!