A common requirement for logic implemented in Azure Functions is to provide a UI created in web content (HTML, CSS, JavaScript). Or to put it another way, you may have a Single Page App (SPA) with it’s backend built using Functions or other BaaS and 3rd party APIs. This content is usually purely static and does not need to be created by the web server. The server just stream files, giving each a unique URL. Or perhaps you have a purely static site for your blog or other non dynamic content; these are becoming increasingly popular again.

Azure provides a number of ways to host purely static web content and this post gives a quick recap of what’s on offer. We’ll ignore installing and managing a server in a VM or container and stick to PaaS-upwards services.

App Service Web Apps

This is the ‘pukka’ web server option with all the configuration, deployment, scaling and monitoring options you’d expect from PaaS. Web Apps make managing servers relatively easy, with a choice of languages suitable for a traditional 3 tier achitecture. However, a simple static server is the least complex configuration available. You just copy your files up to the Web App file space which is then handled by a IIS static server.

Content can be managed from the Portal, via FTP, with version control integration, Visual Studio or the Azure CLI. You can also explore and manage files through the Kudo console or REST API.

As this is powered by a full server you have access to routing features like default document handling and redirection and can add dynamic content as you like.

There is a free shared price tier, though you’ll need to move up to Basic to get multiple deployment slots (eg stage and live), which you can simply swap for instantanious updating.

Blob Storage

Blog storage is very flexible and is ideal for the efficent Static Content Hosting Pattern. Blobs may be any type of content and the blob storage is accessed and managed via a REST API. Any blobs that are given anonymous access are publicly available without authentication. Access is then though HTTP GET with the blob URL strings (paths) organised into containers without any nesting. For example:

Content can be uploaded via the portal, The REST API, Azure Storage Explorer or Visual Studio. Autoscaling is available. There’s no facility for default document handling (/ => /index,html)

Blob storage is very cheap indeed, and is calculated based on storage and bandwidth.

Functions

[Update: 15 Mar 2017] The new Function App Proxies feature offers even more flexibility in specifying URLs (but avoid / for now). In addition, C# Functions can happily stream static content. Antony Chu brings these two points together in his post on Serving Static Files from Azure Functions. Also, currently the Nodejs file share is inefficient when accessing many small files so may have an impact.

By default HTTP triggered Function URLS are of the form

However, you can specify methods (HTTP verbs) and routing in function.json and the ‘api’ segment can be altered or removed in the function app’s host.json.

The flexible Azure Functions with a HTTP return type can return HTML and other text based resources very easily. Just put them in the body and set the content-type header. You can also return Octect encoded binary content (eg images) as Functions support Buffers. But, with nodejs this is less efficient than a server because streams are not supported. Rather, the resources will be have to be placed in a memory buffer in res.body.

You have access to the Function App VM’s file system so can upload static content like images (though space will be limited). As Functions are built on App Service, content is managed in the same ways as Apps and there is the AzureFunctions CLI. Autoscaling is a basic feature of functions, but so is a cold start delay.

If you want to go crazy, you could probably use a something like nodejs module like ‘serve-static’, ‘connect’ or even ‘express’ to have the flexibility of middleware. This would require mocking the node HTTP module objects that pass requests in and out. However state oriented middleware will be useless in Functions and given the previously mentioned lack of streaming only a few of the available options will much use.

Functions used this way with nodejs are really more suitable for APIs when compute or side effects such as DB updates are of more interest than streaming data. Here’s an example – azure-function-express.

Cost are also very low and you have a choice of pure Pay as you Access or a Web App costing.

What’s missing?

You may have spotted that in the above we ignored at least 2 features that are very important in many real situations. Namely: HTTPS access with a custom domain, and access control through authorisation. These are topics for another post.

Categories: Uncategorized

Tagged as: Azure

steve@opendirective.com