Adfolks LLC has formally joined the ZainTECH family Learn more
Blogs Azure functions overview & Good practices for Apps
banner adfolks
blog adfolks
Cloud, Azure,

Azure functions overview & Good practices for Apps


Azure functions allow one to author and execute small snippets of code (functions) without worrying about the infrastructure. Coding in azure functions can be done using JavaScript, C#, F#, Node.js, Python, PHP, batch, bash and PowerShell, and these codes are triggered by events.

Prerequisite knowledge:

Knowledge of serverless architecture Basic understanding of Azure functions

Best Practices

"Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance.” ― Kurt Vonnegut

As every developer abhor to rework on their code, a few proven practices help in delivering a reliable function app to the end-user. Here mainly we will be focusing on three areas, namely

1. Prevent problems 2. High Performance 3. Defensive Coding

Prevent problems

Monitoring your azure functions

For reliable infrastructure, its necessary to ensure that the functions are not getting timed out or throwing exceptions. So have a regular practice of checking for problems in the monitoring section of function app. This will help in

  1. Realtime and historical logging
  2. Viewing exceptions in logs
  3. Getting better insights by using app insights service

Asynchronous Programming

The code should be async without any blocking calls is the suggested programming practice for function app. The function apps’ runtime allows us to make the call async and returns the result in which we can just ‘await’ and handle exceptions seamlessly.

Set Daily usage Quota

The consumption plan for the function app allows us to configure the daily usage quota in terms of memory (size calculated in GB) usage allowed per day. If the application should not exceed the free tier(400,000 GB-s for consumption plan), we can configure approximately 1/31 of that, or 13,000 GB per day (assuming that only one function is there in our app service environment).

High performance

Reuse the code from a common folder

There can be situations where a single piece of code needs to be shared in other Azure functions(say OAuth). In such cases, write your shared code inside a folder in the root of your Function App directory (e.g. “Shared”) and you can import the code in any functions.

By default, the files in that directory won’t be tracked for changes as we add as a custom shared folder. If you want to ensure that as soon as the files change in that “shared” directory, function app should identify the changes and recompile, then you can add your “Shared” directory to the watchDirectories list in host.json file.

Avoid long-running functions

A function can have multiple dependencies; importing these dependencies into a function can cause an increase in load time and unexpected timeouts. So, breaking off large functions into smaller groups of function sets that work together and return responses quickly is recommended.

Use Queues

An HTTP trigger or a webhook function requires an immediate response. So, to return an immediate response, one can use a queue trigger function where the HTTP trigger payload is passed into a queue. Considering the function requirements, one can choose between Storage Queues and Service Bus Queues.

Avoid test functions

Since resources are being shared by all the functions in a function app, it is highly recommended to remove test functions in the Production environment.

Defensive coding

Defensive coding is a technique designed to ensure code correctness and reduce the number of bugs. The following are some of the defensive coding practices for azure function app.

Azure functions are stateless

As azure function being stateless, write code in such a way that it assumes nothing about underlying VM’s or state of the system.

Functions should be Idempotent

The notation of idempotence means that the operation’s result must remain unchanged when an operation is applied more than once. So, ensure that the state of the code remains the same after each function call.


Based on requirements and use-cases, one may choose between languages and runtime for the function app, but the above practices will remain as the baseline for function app.