One of the more interesting current Web development concepts is Jamstack. Popularized by Web application platform Netlify, it’s a Web application model that uses JavaScript, APIs, and Markup (hence JAM) to deliver static sites that aren’t delivered as server-generated dynamic content. The result is a low-impact way to deliver apps that are built externally and served up by a content delivery network like Azure’s or Cloudflare’s.
Jamstack: a new generation of static Web content
With Jamstack there are no dependencies on app servers or technologies like node.js. Instead there’s only standard markup that can be built and tested anywhere and pushed to your servers as you update both content and code. This model works well with modern, devops-driven build processes, fitting in with CI/CD (continuous integration/continuous delivery) platforms such as GitHub, where collaborative development can happen in code branches before pull requests populate a deployment branch and an automated deployment to your site host.
It’s an interesting and increasingly popular way to build apps. Although page code is static, its content isn’t; dynamic content is rendered locally using JavaScript with loosely coupled API connections to other services. For example, a static site could host an e-commerce store by using JavaScript to render catalog content retrieved by a RESTful query against a store service. There’s no direct connection between site and back end beyond the API call, and code in the page can detect errors and warn users. Decoupling Web and application like this, using well-defined APIs, allows application and Web development to work in parallel, simplifying development while increasing the speed of delivery.
That loosely coupled model makes a lot of sense when you’re thinking about adding front ends to cloud-native applications. Both front end and back end can scale independently, using low-latency metropolitan content delivery to cache markup near users, ready to take advantage of those CDN platforms’ cache tools to deliver Web applications to users without having to spin up multiple servers. If you’re using a service such as Azure, the model can offer significant cost savings, as well as reduce the lag between requesting and spinning up a host VM and delivering a response. As fast as Azure can be, it’s often still too slow to keep a customer engaged.
Introducing Azure Static Web Apps
Build 2020 saw Microsoft unveil its own platform for supporting Jamstack-style applications: Azure Static Web Apps. Available in preview, it brings together GitHub, Azure App Service, and Azure Functions in a single workflow, with a Visual Studio Code plug-in to drive development and deployment.
At the heart of the Azure Static Web Apps workflow are GitHub Actions, with a deployment action automatically created when you link your application repository to Azure. This action monitors a specific branch, and when commits are made to the branch it automatically runs a build and deploys the app to Azure. The same process runs when you merge a pull request.
You need both GitHub and Azure accounts to get started. Once these are set up, create a repository for your site. GitHub provides useful templates for common static Web application frameworks, including Angular, React, and Vue. Use these templates to set up scaffolding for a site that can be used to build an app. Repositories can be cloned to local development devices, giving developers access to their usual toolchain.
Building your first static Web app
Once you have a repository for your app with some code in place, go to the Azure Portal and create a new Static Web App. You can add it to an existing subscription or use a free trial, creating a new resource group or working with an existing one, giving your app a name and choosing a region. Next, sign in to your GitHub account in Azure to connect your repository. Choose the repository and branch you want to use. You can now create your Static Web App. In the portal, configure your app settings, including the build settings.
Once that’s all ready, review your settings and create the app. You can change settings by editing the workflow file that is created as part of the setup process. Initial setup should be very quick, with details of the site URL in the resource details.
With your app configured in both Azure and GitHub, the Azure Portal will inform you that it has not received any content yet and to check the status of your GitHub Actions. This link takes you back to your GitHub repository and the workflow that setting up your app has installed. When your code is complete and ready to deploy, run the workflow to build and deploy your site.
The preview includes free hosting for your static content, so there’s no charge for storing your HTML, JavaScript, or images. The service is integrated with the Azure CDN, so that content is automatically deployed where your users are. You can use Azure’s networking tools to manage where content is available and how users can access it, as well as managing staging for live test versions of your sites, with SSL support for secure connections. The preview doesn’t support custom domain names, but these will be available when the service goes live.
Adding API support with Azure Functions
Microsoft has released a preview of a Visual Studio Code extension for working with Azure Static Web Apps, though it only works in the preview Insider release at present. It integrates with the rest of the Visual Studio Code Azure tools, so you only have to log in once to use it. It’s a useful tool, especially if you’re integrating Azure Functions with your site, using them to host APIs for your applications and services.
The static Web app model works well with serverless asynchronous event-driven APIs, as JavaScript features like async await support querying your API. A query is received by the API HTTP end point, which spins up and runs a Function, delivering a response to your application. You’re not limited to Azure Functions with Azure Static Web Apps. You can call any RESTful API and parse the resulting JSON in your code, in the browser.
There’s an interesting aspect to this model that touches another part of Microsoft’s developer story: Azure Static Web Apps are an excellent way to deploy both PWAs (progressive Web apps) and WebAssembly apps to users. Both involve delivering static content that then executes on a user’s computer. Using CDNs can significantly increase the reach of an app without needing to invest in significant infrastructure.
It’s easy to see a future where Visual Studio’s PWA tooling will automatically configure the appropriate workflow to use both GitHub and Azure Static Web Apps, going from editor to deployment in a few clicks of the mouse.