TL;DR Azure Static Web Apps currently only supports Azure Functions v3 with Node.js v12 and HttpTrigger bindings for APIs. See the docs.

First things first, you’ll need the Azure Functions Core Tools. You can install the latest version 3 with npm:

npm install -g azure-functions-core-tools@3 --unsafe-perm true

From the root directory of your static app project, you’ll want to create a new directory and initialize it for Azure Functions:

mkdir api && cd api
func init ...

When I then tried to create my function, however, I received a nice little error message like the one reported here. The issue is reportedly fixed, though I was still finding it happening a few days ago. This comment provides a workaround. I’ll assume those of you following along either have a newer, working version or applied the suggested fix and proceed.

Python

I’ve been learning Python recently, so I thought it would be fun to have a Python API to run alongside my static app and thereby continue learning two things at once. If you, unlike me, have already read through the ever-expanding documentation, you’ll have stumbled upon the docs for APIs and realized where this post is heading.

I added a function using with the following command:

func init --worker-runtime python
func new -l python -t HttpTrigger -n hello
cd ..
git checkout -b python # create a new branch off master
git add .
git commit -m "Add Python api"

Easy peasy.

I then went to GitHub, opened a PR from my python branch against master, and opened GitHub Actions to watch the magic happen.

The build succeeded, and aside from the weird bit about Enumerating repo to find any files with extension 'csproj'..., everything seemed to go off without any problem.

When I navigated to the Azure Portal, however, there were no functions listed. Looking back at the above you’ll notice a few additional lines that I missed on my first glance:

Error: could not detect the language from repo.
...
Oryx was unable to determine the build steps. Continuing assuming the assets in this folder are already build. ...

Something called Oryx is apparently responsible for the builds and apparently didn’t like that I used Python. I’ll cover more on Oryx in a later blog post.

Node

While waiting on the above to run, I also started another branch using node, as I wanted to get a sense for how this all worked. Lucky for me, b/c if you have by now read the doc linked above, you’ll have learned that only Node will work and only on Azure Functions v3 with only HttpTriggers. I lucked out on two of the three. Actually this is worth calling out, so I’ll quote the docs:

Azure Static Web Apps provides serverless API endpoints via Azure Functions. By leveraging Azure Functions, APIs dynamically scale based on demand, and include the following features:

– Integrated security with direct access to user authentication and role-based authorization data.
– Seamless routing that makes the api route available to the web app securely without requiring custom CORS rules.
– Azure Functions v3 compatible with Node.js 12.
– HTTP triggers and output bindings.

https://docs.microsoft.com/en-us/azure/static-web-apps/apis

Here’s how I created a simple Node Azure Function:

func init --worker-runtime node --language typescript
func new -l typescript -t HttpTrigger -n hello
cd ..
git checkout -b node # create a new branch off master
git add .
git commit -m "Add TypeScript api"

I was inspecting the Python build and trying to figure out what happened while the following build ran. Having assumed this completed, I was surprised to learn that the build failed.

I’ve highlighted the issue. The build didn’t fail, only the deployment. However, that was sufficient to cause the build to be marked as a failed build. It turns out, at least during the preview, you can have only 1 pre-production environment per app. Again, read the documentation. They’ve done a great job making sure to address these types of things if you will, unlike me, just read them.

I removed the python environment from the Azure Portal and triggered a rebuild in GitHub Actions.

Azure Static Web Apps sends a link to the pre-production environment in a comment to your pull request (PR)! This makes it really easy to then navigate to your site and start testing things out. (Note the -2 at the end of the sub-domain, which is the number for the pre-production environment.)

Azure Portal

Back in the Azure Portal, you can see the functions and environments deployed for your Azure Static Web App.

To see the available functions, select Functions from the side navigation.

This defaults to the production environment. It will also reset to the Production environment anytime you click the Refresh button.

If you choose a different environment, you’ll see the functions available for that environment.

If you select Environments from the side navigation, you’ll see your production and any pre-production, or Staging, environments you’ve deployed.

The fact that the UI supports multiple gives me hope that the platform will eventually support more than one pre-production environment, meaning that this will be a great platform for supporting feature branch previews, something I’ve been doing with a bunch of scripts in the past.

Promoting to Production

When you merge your PR to master, you will notice that two GitHub Actions are triggered, one against master, and one against your PR branch.

The master branch build will deploy to your production environment. What’s even more helpful and convenient is that the other build cleans up the pre-production environment!

I love this! Cleaning up unused environments was always a tedious process for my multi-branch support I set up in the past. I really appreciate that Azure Static Web Apps provides this infrastructure.

In the Portal, you’ll notice our Production environment now has the function deployed.

We can also hit the API against the production endpoint.

And of course, our Sapper app continues to cheer us on!

Wrapping Up

While you can certainly find a much terser walkthrough in the Azure Static Web Apps documentation, I thought this meandering walkthrough worthwhile for showing what may also be possible and what we may expect to see in upcoming releases. I have several planned follow-up posts to show some current work-arounds, as well as some interesting use cases, so stay tuned.

You may also be interested to see what the rest of the community is creating. You can find a collection of samples on GitHub.

Microsoft has not be sitting idly by either. The WCF team is working on a new Web API to provide WCF developers simpler, more direct control over HTTP services. This is no slouch effort either. In fact, aside from OpenRasta, it may be the most thorough HTTP implementation available.

While exciting on their own, the best news, imho, is the .NET HTTP Abstractions group, started by Scott Koon. This group has been working on a standard, currently called Open Web Interface for .NET, or OWIN. It’s intent is to define a common interface by which any application can talk to any server. The idea comes from the Web Server Gateway Interface (Python) and Rack. The primary difference in this and other similar specs is the inclusion of asynchronous network I/O as a primary concern. Discussions are still underway and include nearly all of the developers of the aforementioned projects, as well as some members of the ASP.NET team.

If you are a F# fanboy, such as myself, you will be happy to know that F# is not silent in this space. WebSharper is now in its second iteration, and my own projects, Frack and Frank, are making nice headway. Frack is now a web server, similar in spirit to node.js. Frank is, as the name implies, a Sinatra-inspired clone that takes cues from the Haskell Snap framework. If you are interested in parsing and agent-based development, you’ll find more examples of how F# handles these things as these two projects progress.

Expect to find more posts (shock!) coming soon describing in more detail the WCF Web APIs, OWIN, Frack, Frank, and more. In the meantime, join the discussion on the .NET HTTP Abstractions group!