Can Azure Functions be developed offline?

1
votes

Can I develop and test Azure Functions completely offline (no network connection)? I understand Azure Functions can be debugged locally but that's not the same as working completely disconnected from the Azure platform.

I found a few references in the Azure documentation that I interpreted to mean being connected to Azure is required to run Azure Functions, even locally.

FWIW, I'm using the Azure Functions tooling in Visual Studio 2017 (15.3.2)

2
azureazure-functionsazure-functions-runtime
It would depend on what kind of binding are you using. If you're using Azure Storage Queues or Blobs, then you would be able to develop and test Azure Functions locally. You would be using Azure Storage Emulator in this case. - Gaurav Mantri
@GauravMantri - According to the documentation, We recommend that you use an Azure Storage account when developing locally. Use of the Azure Storage Emulator is not supported by Azure Functions tools. If the documentation is correct, then offline development of any kind is not possible, correct? - DenaliHardtail
I remember using storage emulator for testing functions locally. Also please take a look at this blog post: eliostruyf.com/…. - Gaurav Mantri

2 Answers

2
votes

The answer is no. Although you can use some bindings in a disconnected way such as Azure Storage through Azure Emulator, not all of them offer a way to work disconnected.

0
votes

It depends. Some infrastructure (like [Singleton], which is used by Timer) need a storage account since they use blob leases for coordination. Logging can be disabled.

On one extreme, if you're binding to cloud resources (ie, DocDb) or using cloud-based triggers, then clearly you must be online. Some bindings (like blob) can work against a storage emulator, but this a case-by-case basis.

On the other extreme, Azure Functions parameter binding makes it very mock-friendly which would let you invoke your functions directly offline (and also in unit tests) rather than go through the Azure Functions listening + dispatch logic. For example, you can bind a Blob to a Stream or TextReader, and then directly invoke your function and pass them streams that are bound to in-memory or file system. The IAsyncCollector interfaces are also very mock friendly. Our own unit tests in the WebJobs SDK heavily leverage this (see https://github.com/Azure/azure-webjobs-sdk/blob/b8674651654f27a51ffadd0d38b4f89ce246b7a1/test/Microsoft.Azure.WebJobs.Host.UnitTests/Indexers/ReturnValueTests.cs as an example)