Azure technologies evolve so fast sometimes we lose track of what’s happening. One day, a simple technology is created, on the next day, it becomes something huge, in a blink of an eye. I’m not even sure if my recollection of the story will be correct.

The launch of the GA version of Static Web Apps, on this last May 12, brought a very interesting new feature and made me get out my data-silo to study and write about it.

The first time I heard about static web sites was in Microsoft Build last year, MS Build 2020. It was (and still is) a feature linked to storage accounts. When enabled, it creates a special container called $web and exposes it as a website with no server technology, only client-side development.

 

 

 

This was already very good, but Microsoft decided to go beyond and create the Static Web App. A Static Web App is a site with client code but can also include API’s. It’s directly linked with github actions that will define the deployment for the static site content and the API functions in many different languages.

In a static web app the storage is underneath. We don’t need to take care of it. The API’s are deployed using Azure Functions architecture, but not visible for us on the portal, only accessible to the static web app. The Azure Function architecture is used underneath with docker, but we don’t need to mind too much about this.

New Feature: We can map existing Azure Functions from any of our subscriptions to the API path (usually /API) inside the static web app.

 

Static Web Site

On a static website, you can implement any client-side framework as long it has no server-side dependency. These frameworks can make calls azure functions without many problems.

However, the front-end application is in one domain, the azure function is in a different domain. This brings security configuration details such as CORS. Both pieces, front-end and functions, are independently managed.

Static Web Apps – Before

The SWA allowed us to create API’s together the App and the deployment tasks would handle them. Internally, it uses the Azure Functions architecture, but we don’t need to handle them.

The API’s will be in the same web domain, as if they are inside a folder such as “/API”, but internally the Static Web Apps system is handling them using docker and we don’t need to know too much about it.

 

 

However, the API’s created inside a static web app can’t be accessed outside the App. They don’t become real Azure Functions and can’t even be shared between different Apps

You still can access Azure Functions, but under the same limitations as in a static web site

 

Static Web Apps – Now

The new feature is simple: Bring Your Own Azure Function (BYOF ?)

The Static Web App will host the static files and the existing Azure Functions will be mapped as if they were a folder inside the Static Web App

 

Here are the advantages:

• The functions can be re-used in many Apps and different scenarios
• The function is called in the same domain context, simplifying the management of CORS, sessions, cookies and so on
• Following the micro-services architecture, the Azure Functions are not tied with the UI

Limitations:

• It only works on standard plan, not on the free plan
• We can link only a single function app, we can’t mix different function apps
• At this moment, it only works in production environment

Where you can Start

• What is Static Web App
• Building the Static Web App in the Azure Portal
• Setup local development for Static Web Apps
• Create your first Static Web App with no framework
• Create your first Static Web App with Angular
• Bring Your Own Functions to Static Web Apps
• Azure Static Web Apps Documentation

Conclusion

We have one new method to deploy static web apps, breaking the front-end from the back-end. The new method has new advantages to offer.