{"id":91152,"date":"2021-05-18T17:30:00","date_gmt":"2021-05-18T17:30:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=91152"},"modified":"2021-05-17T19:18:15","modified_gmt":"2021-05-17T19:18:15","slug":"azure-static-web-apps-bring-your-own-function-byof","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/blogs\/azure-static-web-apps-bring-your-own-function-byof\/","title":{"rendered":"Azure Static Web Apps: Bring Your Own Function (BYOF)"},"content":{"rendered":"

Azure technologies evolve so fast sometimes we lose track of what\u2019s happening. One day, a simple technology is created, on the next day, it becomes something huge, in a blink of an eye. I\u2019m not even sure if my recollection of the story will be correct.<\/p>\n

The launch of the GA version of Static Web Apps<\/strong>, 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.<\/p>\n

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.<\/p>\n

 <\/p>\n

<\/p>\n

 <\/p>\n

 <\/p>\n

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

In a static web app the storage is underneath. We don\u2019t need to take care of it. The API\u2019s are deployed using Azure Functions<\/strong> 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\u2019t need to mind too much about this.<\/p>\n

New Feature:<\/strong> We can map existing Azure Functions from any of our subscriptions to the API path (usually \/API<\/em>) inside the static web app.<\/p>\n

 <\/p>\n

<\/p>\n

Static Web Site<\/h2>\n

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.<\/p>\n

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<\/em>. Both pieces, front-end and functions, are independently managed.<\/p>\n

Static Web Apps – Before<\/h2>\n

The SWA<\/strong> allowed us to create API\u2019s<\/em> together the App and the deployment tasks would handle them. Internally, it uses the Azure Functions architecture, but we don\u2019t need to handle them.<\/p>\n

The API\u2019s<\/em> will be in the same web domain, as if they are inside a folder such as \u201c\/API\u201d<\/em>, but internally the Static Web Apps<\/strong> system is handling them using docker and we don\u2019t need to know too much about it.<\/p>\n

 <\/p>\n

<\/p>\n

 <\/p>\n

However, the API\u2019s<\/em> created inside a static web app can\u2019t be accessed outside the App. They don\u2019t become real Azure Functions and can\u2019t even be shared between different Apps<\/p>\n

You still can access Azure Functions<\/strong>, but under the same limitations as in a static web site<\/p>\n

 <\/p>\n

Static Web Apps – Now<\/h2>\n

The new feature is simple: Bring Your Own Azure Function (BYOF<\/em><\/strong> ?)<\/p>\n

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<\/p>\n

 <\/p>\n

<\/p>\n

<\/p>\n

<\/p>\n

Here are the advantages:<\/p>\n