A Simple, Serverless API using Azure Tables & Functions

Who would’ve thought developing in a Portal would be so bearable.

Whilst serverless is in no way a new technology, it is only recently whilst studying for my 532 Microsoft Exam that I have truly come to enjoy the power of products such as AWS Lambda and Azure Functions. Whether it be for scalability, costs or ease of implementation; there is merit in taking the serverless approach with your cloud based solutions. This piece is not necessarily a fleshed out tutorial of how to work with Microsoft’s Azure Functions but more of an exploratory piece on just how easy it is to create a database backend “API” of sorts all from within the Azure Portal itself!

Note that I don’t necessarily advocate that this is the way you should develop Azure Functions. Microsoft supports using Git and other version control systems for working with Azure functions, as well as providing an Azure Functions CLI for running functions locally.

Setting Up

Assuming you have an Azure Subscription (if not sign up here it’s free), locate the “Serverless Function App” resource in the marketplace. Whilst usually I’d recommend you create your resource group and storage account seperately, for the purposes of a concise process we’ll create both with the function.

For those who are unsure about the Azure jargon, a Resource Group is essentially what the name implies and is a collection of Azure resources which are the services you use on Azure. A Storage Account is a type of resource which provides multiple types of storage solutions all under the one resource including file, blob, table, queue and more. We’ll be focusing on using Tables for this tutorial which Azure describes as ;

NoSQL storage for unstructured and semi-structured data — ideal for web applications, address books, and other user data.

When creating your function app, Azure will pre-fill the names for the resource group and storage account as you type. For the hosting plan I’ve gone with Consumption as that is the type in which you are billed for usage rather than uptime. Location is very much dependent on, well, your location so it doesn’t really make a different to the function itself. Clicking create will validate the Azure Function configuration and add it to your Function Apps.

Let’s Write Up Some Functions!

Once the Function App is deployed you can find it in the aptly named “Function Apps” section of the Azure Portal. Before we get into creating the functions I like to modify my CORS origins to allow all (*) as for the purposes of this article defining the specific origins I’m using is unnecessary.

Click on your function app and go to Platform Features -> CORS and then remove all the allowed origins, add a single origin of *.

Once those changes are saved, go to the Functions section of your Function App and click the new function button. This will display all the templates Azure has to offer. For this tutorial we’ll be using the HTTP GET and HTTP POST templates as the template includes everything we need to connect to our Table Storage.

So many options :O

We’ll start with HTTP GET, for this tutorial I’ll be using C# but as I’m admittedly relying on generated code for the most part you’re more than welcome to use any language you wish.

Let’s go with a food theme for a change.

For this tutorial we’ll be adding and retrieving items from a food database. For the most part it is up to you what you name your function, what will need to be changed is the table name and storage account connection. The table name can be anything as Azure will create a table if it doesn’t exist already, and to retrieve your storage account that you created previously click the “new” button and select it from the list of options. Repeat this process for HTTP POST.

First we’ll edit our GET function to make it a little bit more our own. Opening the function in the Azure Portal will open up a monaco editor with our function in it. If you are using a strongly typed language like C# for your function, Azure will have generated you a TableEntity for the function (by default its person). Let’s edit this a bit to be more unique…

As you can see a TableEntity is very much a Plain Old C# Object with the exception of the RowKey and PartitionKey. Whilst this is very much not an Azure Functions concept and more of an Azure Tables piece of info, to sum it up a RowKey can be thought of as a Primary Key in the table. We can use it to uniquely identify and easily retrieve an entry in our table. The PartitionKey is a bit more complex and defines how Azure will distribute the entry in your storage. It can be assumed that elements with the same partition key are kept in the same partition of your storage and so can easily be queried and batched together.

As you can probably guess, for this example I will be using the name of the FoodItem as a RowKey, with all items partitioned the same.

I also need to refactor the function for the HttpResponseMessage so that it works with the correct data types.

With those changes our GET endpoint is done! All of the implementation achieved within the Azure Portal editor. For testing the function we can copy URL from the Get Function URL button in the top right hand corner and query with Postman, the response an expected empty array.

Your navigate over to your POST function, for mine I wrote the following code;

Whilst the model remains unchanged, there are some things to note in the function itself.

• Emphasis on nullable data types, especially int? for example.
• My validation is pretty much ensure that name and rating are present.
• There is no need to explicitly set a PartitionKey and a RowKey like in the originally generated code as we take care of that in the constructor and the Name setter.

Once implemented, save your post function and ensure there are no errors in your log. If all is good congratulations! You just implemented GET and POST endpoints utilising Azure Functions backed by Azure Table storage. To test it let’s open up postman and send some data to the POST endpoint;

Nothing was more satisfying than the 201 I received for this

GET Endpoint works as expected.

Whilst there’s so much more to explore with Azure Functions, I’m hoping this was a good primer into just how easy it is to get started with them.

If you enjoyed this article please give us a clap as it inflates my ego and fuels my need to write more pieces.

PS: Just wanted to recommend Scott Duffy’s Udemy Course “70-532 Developing Microsoft Azure Solutions Certification” for being the reason for me wanting to write this article. Definitely worth checking out as it’s incredibly in-depth, up to date and modelled around the Microsoft Examination of the same name.