Azure Functions CRUD with Table Storage & JavaScript / NodeJS

Thomas Pentenrieder
Published in
5 min readOct 4, 2018


UPDATE: This post is not up to date anymore, so I’ve wrote a new one here for Azure Functions v4 with TypeScript:

Old post:

Using Azure Functions to provide an HTTP API for database access is probably one of the most common scenarios. However, there don’t seem to be many tutorials on how to actually do this. So here’s how you can build a nice little API to Create, Read, Update & Delete (CRUD) records from Azure Table Storage.

TLDR: If you just want to see the source code, head over to my GitHub repo!

We’ll be using NodeJS and Version 2 of the Azure Function Runtime which was officially released just a week ago:

Before we actually get to the code though we have to talk about some potential pitfalls, especially when comming from Version 1. With V2 there have been a few changes that we need to be aware of. When creating a new JavaScript function in the portal it will essentially look something like this ( I’ve omitted most of the logic for the sake of brevity):

Compared to functions created with v1, there are two distinct differences we have to be aware of.

First, there’s the async keyword preceding the function which can easily be missed (as did I) but matters quite a bit. This means the function will autmatically notify the runtime once it has finished. You can read more about this here.

This leads us straight to the second change — there is no more call to context.done() as it’s not required anymore. In fact, if you try to call it yourself inside the function you’ll get an error:

Don’t use context.done() in an async function

Less code to take care of — sounds good, right? Sure! But only until at some point your code returns while it still should be running…

That can happen to you when you are using the very common callback pattern for asynchronous code inside a function marked as async. And unfortunately that’s exactly the way the Azure Storage SDK for JavaScript is working.

Reading from a database using the Azure Storage SDK with a callback function

In this case we would never see any data returned from an async function as it would always return a 200 status code by default before the call to the database could even finish.

How do we fix this?

The easiest way for now is to just remove the async keyword and go back to handling the call to context.done() ourselves. We could also manually wrap the calls to the Azure SDK methods in Promises, but that’s a topic for another time.

The Azure Storage SDK for JavaScript is currently being rewritten making use of the modern aync/await pattern. Unfortunately the first release only supports BLOB storage, so we’ll have to wait a bit longer for Promise-based Table Storage access.

If you want to get a better understanding of all this asynchronous JavaScript Mumbo Jumbo I encourage you to read this great article explaining this whole mess:

But now, let’s get to some code!


We start with installing the required npm packages into our Functions App. We’ll be needing the Azure Storage SDK as well as a way to create unique identifiers for our database entities. For this we’re using the uuid package as JavaScript does not have a built-in tool for this.

> npm install -s azure-storage

> npm install -s uuid

Then we’ll create four different HTTP-triggered functions, one for each CRUD request. We could certainly do everything in one single function, but I personally prefer my functions nice and small, even if there’s some duplicate code.

Inside thefunction.json files we update the methods field to reflect what we’re trying to do with each of them, so

  • ItemCreate => POST
  • ItemDelete => DELETE
  • ItemRead => GET
  • ItemUpdate => PUT
Azure Functions JavaScript CRUD Folder Setup

Afterwards we create a table inside our Storage Account. I recommend using the Azure Storage Explorer for these kind of things.

Lastly we’ll need to provide the database connection details for the Function App. Since it’s not a good practice to put any kind of credentials inside the code we can simply add the connection string to the Application settings using AZURE_STORAGE_CONNECTION_STRING as the key. The Azure Storage SDK will then automatically get this value when we create our TableService. For local debugging we can also add the connection string to the local.settings.json file.

Now lets have a look at the code.


To store an object in Azure Table Storage we’re gonna send it to the backend inside the body of a POST request. Depending on your partition strategy for the Table Storage we have to add PartionKey & RowKey properties to the object before we can store it in the database. I’ll be using a single static PartitionKey and a GUID for the RowKey to keep it simple for now.

We also should make sure the object is “flat”, so there are no nested properties as they can’t be stored in the table, but that’s not in the scope of this posts.

Here’s the complete Create-code with detailed comments:


Here we can either pass an ID as a parameter to get the desired object or we can just call the function without any further input and get the top 100 records from the database.


Updating a record is basically a simplified create since we already have the PartitonKey & RowKey set. You can also choose to merge two objects instead of replacing the one in the database.


When deleting a record we usually only require the ID. However, the Azure Storage SDK only takes an object for the deleteEntity() method. The easiest way then is to create a new object only consisting of PartitionKey & RowKey to identify the record we want to delete.

And there we have it! Once again, here’s the link to the full code on GitHub.

Now, unfortunately this is not really a nice REST-style API yet, but hopefully we can look at that in a different article.


Here’s part 2 explaining how to turn this into a REST API.



Thomas Pentenrieder