At TangoCode, our vision is to support all of our applications with a serverless architecture in the backend. In the beginning, many of our projects were using AWS services, so we started there. It wasn’t long, though, before we needed to begin using Azure, as well.

Every provider offers different services for various application requirements. In our case, we needed to build a transactional application, so our requirements were pretty basic (except for the multitenant piece, but we will cover that solution in another blog). We needed a place to store data, a mechanism to extract it, and the ability to securely expose that mechanism so our SPA front end could interact with the data.

How does that translate into needing Azure and its services? Here’s a chart to lay out the big picture:


Cosmos DB (Previously DocumentDB)

Its Azure’s own NoSQL database. You can ask why we decided to use a NoSQL database? That’s an interesting discussion for another time. While Cosmos DB has many exciting features – aside from everything that comes with being a NoSQL – its most interesting element is the use of SQL for querying and updating collections. This is an excellent feature for developers coming from the SQL world, as it allows us to leverage our existing knowledge from day one.

Azure Functions

The objective of an Azure function is to receive an input (in our case from API Management) and then produce an output, typically from querying Cosmos DB. This is the main component of our serverless architecture and where all the business logic of the backend resides. This is also the only place coding takes place in the architecture.

Azure functions support many programming languages, but we chose Node.js. Why? Our development team is composed of multiple full-stack Software Engineers.

Here at TangoCode, our engineers don’t specialize in a single technology. Instead, we are a team of technology enthusiasts. We all like to explore as many techniques as possible, and our team benefits from that exploration. Nevertheless, there’s a limit on how enthusiastic a group can be before you start losing perspective and performance. Fortunately, JavaScript and Node.js have been a great help in this process, particularly for their portability.

With Azure functions and serverless architecture, you can create functions to do anything – from reading the DB and returning data to sending an email and interacting with other Azure services. Even better, the system does all this without the requirement that you set up and reserve a server. You only pay for the cost of executing that function.

API Management

Once we set up our database and Business Logic, is time to set up our REST API’s endpoint. Configuring an API with API management is quite simple. You have many templates to choose from, although you can create one from scratch if you prefer. The setup process generates a base URL for your endpoints, which you will need to define manually. You can create a dynamic URL using string templates like “path-to-resource/{id}” and anything else you would expect from an API management tool.

One element of API management we found challenging was how to link the system to our Azure functions. While we expected a setting or property that offered a pop-up list of functions, we found a system that was operating at a much lower level. This makes sense when you consider the fact that API management is nothing more than a gateway that takes an HTTP request and forwards it to be processed.

All Azure functions have an endpoint of their own, with a function key to authorize use. You will never call your Azure function directly from your front end since it would expose your function keys. It would be a massive security breach. This is where API management comes in. API management adds an extra layer of abstraction, validating the HTTP request. If validation is successful, it forwards it to the Azure function identified within its function key, which we added as the “x-functions-key” header by defining the policies of the function.

Other policies you will need to add are, i.e. CORS, and very importantly, the “validate-jwt” which takes care of authorizing the API. You can also define policies to a group of APIs or each API individually. We choose to define CORS and validate-jwt to the whole group and the set x-function-key header individually, as each endpoint links to a different function.

This covers pretty much all of our architecture. We will leave the step-by-step tutorials for other blogs. Before we close this post, though, let’s cover the idea of microservices briefly.


Microservices is more a conceptual method of grouping functionality or architecting an application to make it easier to maintain and scale. There is no tool or formula to define what each microservice should include. It is the architect or tech lead’s job to find a balance that prevents you from ending up with one large microservice or one microservice per function.

In Azure, we implement microservices in Azure Functions and API Management by creating a “Function APP” and an “API” respectively per microservice. A Function APP is nothing more than a container where we define one of many functions. An API, meanwhile, is the base path on top of which you can define endpoints.

We will cover the step-by-step of these features in future posts. We hope this gave you a quick start guide on what it takes to build a serverless application with Azure.

Thanks for reading.