The Azure Functions team has again joined us for another monthly live webcast by staying remote and safe.
In this live webcast Jeff Hollan, Anthony Chu joined us to update the Azure Functions space’s latest happenings.
Without any further delay, let us jump in as there are tons of updates are waiting.
What is new?
- Private endpoints connection GA: If you deploy your Functions to a premium plan, join it to a VNet, and you want to have an HTTP trigger. They get triggered only by your VNet address like 10.0.0.1. The technology used to make that happen called Private endpoints. You can use them as it is now generally available for both Windows and Linux.
- Versionless Key Vault and autorotation: If you want to grab the application settings or trigger connection string from the Key Vault, you will have to pin a specific version to the secret. But now, you do not have to include the secret version; you can say this is the secret and grab the latest.
- .NET Preview 5 + some docs: There is a new document (.NET isolated process guide for .NET 5.0 in Azure Functions) in the concepts doc under languages which breaks down the isolation process. If you are interested in learning how this works and some of its capabilities, you can use it today with preview 5, but it does not provide any quick start steps there yet will be landing very soon.
- New Static Web Apps config file (azurewebapp.config.json): Static Web App has a new configuration file. In the past, we have had a file called routes.json, where this file still works, and there is no plan to get rid of it anytime soon. There are two problems with routes.json like you can only put routes information in there, and it does not have a specific name.
These problems get solved in this new configuration file, and it also has a particular name called azurewebapp.config.json.
- Tatsuro Shibamura – Best Practices for Graceful shutdown in Azure Functions
- Jen Looper – Blast Off With Azure Advocates: Presenting The Azure Space Mystery
- Anthony Shaw and Simon Waight – New Breakpoint: Episode 1 – Python and Azure Functions
- Tom Hind – Moving from servers to Server(less)
- Marc Duiker – Durable workshop: notify support on the incident
- Dan Bass – Building a serverless CMS on Azure
- .NET 5 production release (Azure CLI/ core tools/ VS Code)
- .NET Visual Studio templates and service
- Key Vault behind VNet in Premium functions
- Node 14 GA
- Durable Python GA
- New App Service Authentication UX
- Improvements around networking and premium functions
- Static Web Apps – App Insights, CLI/emulator, apex domain, Azure DevOps, Jekyll build
Using Azure Static Apps together with Azure DevOps
Azure Static Web Apps already had support for GitHub actions, but it’s taken a little while to get the support into Azure DevOps, and you might now actually be able to see the Static Web App tasks in Azure DevOps, but the thing is how to use it.
Anthony will now show some of the UI stuff that will be lightning up in the next few weeks, which allows us to use the Static Web App tasks in Azure DevOps. But if you want to use it before the UI gets rolled out, Anthony will post some instructions in the GitHub issues [GitHub issue number 5 is for Azure DevOps] on how you could set Azure DevOps for Static Web Apps.
There is now a new radio button included in the deployment details section using which you can easily opt-out of creating Static Web Apps using GitHub actions. Select “other” to use Azure DevOps for deploying Static Web Apps.
Click “Review + Create” to create the Static Web App.
Go to the Static Web App and then click Management deployment token, which you can use to set up Azure DevOps.
We will now see what that looks like in Azure DevOps. So, the goal is to set up the pipelines using YAML, and the below picture shows the content in azure-pipelines.yml.
The below pictures show how it looks like when the pipeline runs. You will see the GitHub actions; the same container we use is running here. So, the capabilities about how we build your app and all that kinds of stuff you will get with Azure DevOps.
Currently, it’s a little bit manual on how you set it up as well as we are still trying to figure out how we can do the pull request environments. We don’t quite have the same hooks as we do in GitHub actions. So, we need to figure out how to make that work, but if you want to deploy from your Azure DevOps repo, you should be able to do that super soon.
Next, we are going to talk about how to run Static Web Apps locally. So, typically your local development experience is not too bad, especially if you have a front end and use your React app server or Blazor dev server or npm start or .NET watch run or something like that your app starts up.
So, now Anthony will be showing a demo of deploying Static Web Apps locally. We have a CLI that we are already working on, but it’s very much in the early days, and hence it can take a couple of weeks to get ready.
Also, Anthony gives a shout-out to Wasim and Aaron Powell on the cloud advocacy team, who have been working on this emulator.
Let’s start with the demo!
There is a Blazor app, and it is pre-built, but you can actually use it with the Blazor dev server as well if you wanted to and have an API app called the Function App. In the past, you have to start the two things separately and then try to figure out how they work together, but you no longer have to do this with a Static Web App emulator.
The picture below has got many commands, and start is one of them, so you can say start Static Web App and then basically give it the folder name where your static assets are, and it will serve it. You can also take a URL if you happen to have the React App server or React dev server started. You can pass the URL there and tell where the API App is an API.
Then, run the app and start it locally.
Then, go to localhost:4280, and you will be able to see a Blazor App. It is a pretty standard app that works, but you will see the Login button in the right corner.
If you click any of the options given below login, a new page will open.
Just pretend to be anybody you want, give it any roles, and you can log in.
We have logged into the Blazor App now.
And it lights up the different path where it’s making the call to Azure Function, and you can finally log out.
So, now there is a React App in the front-end folder, Function App in the API folder, and some launch configs set up as shown below.
Run it, and it’s going to start the React Dev server, React App server, Function App, Emulator, Edge, etc.
Now the Edge opens up, and we have everything up on the screen at once. You can now select the ‘Click me’ button, and it hits the breakpoint in the React App.
Run it, and that hits the breakpoint in Function Apps.
You can also do things like live reloading. So, you can easily change the background colour, save it and will be able to see the changes instantly.
You can get a tight inner loop now with Static Web Apps locally on your computer.
The last thing we will talk about is Node 14 that will be in General Availability soon, and there are lots of new features coming with Node 14.
We are introducing the support for ECMAScript modules, and this will be in preview because it’s currently still marked as experimental. We will be using a slightly different extension (.mjs), and when you do that, the node worker will know that we are using ECMAScript modules.
This module is going to be the future for Node 14. It’s going to be a node standard module system in the future. It’s still relatively new, but we are offering preview support to get feedback.
Here is an app whose Durable Functions gets converted entirely to use the Node 14 features and ECMAScript modules.
The below picture shows a bunch of tests. Instead of running it locally on the machine, we use the fan in and fan out Durable Functions’ capabilities to run in the cloud.
You can write these files that look precisely like jest or mocha file and try to run them in the cloud. It is on GitHub; go to Anthony Chu’s GitHub Repo and grab the code.
Result of the above code running in the cloud
Question and Answer Session
- Do we have PowerShell support for Static Web Apps?
- I just started with the Azure App Config service. Trigger-based functions produce a “may not scale” warning when pulling values from Configuration. Is this being addressed?
- Anthony said the new .net5/worker wouldn’t support durable functions/entities in a blog post – so what is the plan?
- Any document for the code sample for the Retry Policy?
- Is there any limitation on Premium and Consumption Linux Apps getting deployed to the same resource group?
We have solved this issue for Key Vault today but haven’t yet solved it for App Config, but it will improve a scenario of interest in the future.
The solution for this issue takes place in the road map blog that we are posting soon. Our guidance right now is if you want to use Durable Functions, the only option is to stay on .NET core 3.1, and we are also going to give In Process hosting model for .NET 6 where you will be able to run the Durable Functions. But the only glitch right now is you won’t be able to that with .NET 5.
Here is a link to the document where you can see the Retry Policy Preview.
Yeah, this is a limitation. I hope that we end up finally solving it in the next few months.