In this workshop you're going to deploy a JS app to our Azure Services. Obviously, we don't want to do this manually, so you're going to use GitHub actions to streamline this experience. Now that our App is on Azure, we want to make sure that we're aware of crashes and performance issues, so we'll add some App Insights in the mix. During the workshop, we'll show some cool features you could leverage!
Publishing, Automating and Monitoring your JS App on Azure
AI Generated Video Summary
Welcome to the workshop where we will run a static web app on Azure. We'll cover the necessary ingredients for running a web app online, including storage, reverse proxy, SSL offloading, load balancer, API server, routing, global scalability, and CI/CD processes. We'll deploy a shopping list app and extend it with additional functionality, API, security, and monitoring. Azure Static Web Apps simplifies the process of hosting static web content and backend APIs, providing a managed environment. The workshop covers the deployment process using GitHub actions, configuring fallback routes, creating and deploying Azure static web apps, adding APIs with Azure Functions, and troubleshooting deployment issues.
1. Introduction to Workshop and Deployment
Welcome to the workshop where we will run a static web app on Azure. We'll cover the necessary ingredients for running a web app online, including storage, reverse proxy, SSL offloading, load balancer, API server, routing, global scalability, and CI/CD processes. We'll deploy a shopping list app and extend it with additional functionality, API, security, and monitoring. You can choose your preferred framework, but we'll be using React in this workshop. Now, Nick will explain the details of what we'll do using Azure Static Web Apps.
So welcome to this workshop. I'm Susanne Daniels, I work for Microsoft. Here's my colleague, Nick, also working for Microsoft. We're developer engagement leads, which means we get to do stuff with developers around a wonderful topic of Azure. We just try to help you discover nice things, show you what's out there. We run workshops like this to help that and we are really excited to have you all here. That's great.
Today we are going to run a workshop where we will have a static web app and we are going to run that on Azure. Now, before we are going to start with the workshop. Let's briefly take a moment to think about all the ingredients you would need to run your web app anywhere online. There's this storage, you have to put your contents somewhere. Most likely, you will have some reverse proxy with some SSL offloading. You have to create a certificate, probably there will be also a loan balancer for the sake of availability. You also need an API server to run your API. You must make sure that your routing is in order so you are able to proxy the requests to the API server and get answers. And also, well, there's this whole thing to make your application globally scalable. So you could think of maybe a CBN somewhere in this whole setup. And well, to make it somewhat agile and more modern, you would probably have some CICD process you're using, and for that, well, you'll probably use some tooling as well to help you with that. So come to think of it. And, you know, most people do this nowadays because this infrastructure is already there from your company. Maybe you set it up yourself, you automated everything, but there's a lot of stuff underwater which you need to maintain and to have to run your application. So what we are going to do today is run it on Azure. And for this, we will use Azure services.
Now what are we going to deploy? This is a shopping list app. And well, I don't know about you, but the past year I'm so experienced in putting things in a shopping list. I never knew I needed so much stuff being at home all the time. Well, anyways, we are going to deploy this application and it will be a fairly basic application which we will upload, but then extend it. We will add functionality. We will make sure that there is an API, you know, to make the app somewhat useful. We will think about security monitoring. So there's a few things we will add after uploading the application. Because, well, we want it to be as real life as possible. Just for the sake of experience now, you can choose any taste, any flavor you would like. If you say, well, today's Angular, good, is felt a few, great. We are going to run with React because, well, obviously this workshop is for React. Some of it, so... But we won't hold a grudge against you if you choose another path. Just keep in mind that's when you run your own flavor, that you will have to keep in mind that, well, where we use maybe React in a name, you would probably have to use Vue in your name. Well, that's a good thing to take into account. Okay, so running this stuff on Azure. Nick, what are we going to do exactly?
2. Getting Started with Azure Static Web Apps
To get started, you need to have your source code in a GitHub repository. With Azure Static Web Apps, you can trigger a GitHub action to automatically deploy code changes to your target environment. Azure Static Web Apps provides a managed environment for hosting static web content and backend APIs, taking care of all the underlying infrastructure. In this workshop, we'll create, deploy, and extend the app, adding CI/CD, security, and monitoring. This saves time on debugging and infrastructure setup.
Now, how do you get started? So everything started from basically your source code, which is living in a GitHub repository. And so what you ideally want to have is that as soon as you make any changes to your application in your GitHub repository. So you do either a push to a specific branch or you do a pull request. As soon as that code change lands in your repository, you want to have an automatic deployment of those changes in your target environment. So you want this continuous integration, continuous deployment process to happen. And this is what we're going to enable with Azure Static Web Apps, is really kind of from your code, trigger what is called a GitHub action. And we'll look at the details of that on how that works and what the different pieces are in there.
3. Workshop Prerequisites and Azure Sandbox
In this workshop, we'll cover the prerequisites for running the workshop, including installing Node and setting up VS Code. We'll also use Azure functions to create the API. You can find all the instructions and download links at aka.ms/runSWA. The good news is, you don't need an Azure account. You can use the sandbox on the Microsoft Learn website to try out our services and go through workshops at your own pace. Just sign in and choose a way to sign in.
Then we are going to dig into the actual work. We will create this application, we will deploy it, and we will then extend it. So that's the later part of the workshop. Now, the boring stuff, the prerequisites. So you see the URL down below. It's aka.ms.slash run SWA, and this is the page where we put all instructions but also all links to the stuff you need to install or you might want to install. So let's walk through that. The first one is you would have to make sure that you have Node installed and it is in your PATH. So, especially if you're a Windows user and you installed Node, that's good. Take into account that you need to create a custom setup and make sure that add to PATH is selected because otherwise you will run into some trouble down the road. Well, we could help you with troubleshooting that, but maybe it's better to just avoid that thing. Well, the instructions for Linux, you can find them also on the screen. But of course, if you go to aka.mslashrun.swa, you will directly be linked to the correct instructions. So that's the first one. The second one, well, you can use basically any editor you want. You can use Vim, you can, we don't care, Sublime, it doesn't really matter to us. We don't have any bias. For the workshop, it will be interesting to use VS Code. You can find the download link also at aka.ms slash run SWA. Once again, that's the URL where we keep all the links to the downloads and the instructions for this workshop. Why is it fun to use VS Code? Well, why not, we are using it, we're going to tell some things about it. And there's this great extension which you can use which will really, really make your workflow for this workshop more easy. So probably it will help you having the best possible experience for this workshop. Once again, no words if you want to use Vim, that's cool. Emacs, even more cool. And then there's the actual functions work tools. Now we are going to use that one to make the API. Simple as that, yes. So those are the things we need to do to make sure that we can run the workshop. So that is install mode on your machine. Download VS Code, after you download it, VS Code, you can install the Azure static web extension. Nick will show this to you how you can find this. As soon as he shared a screen later on. And then there's the Azure functions or tools. And if you install that you know why we think it's funky. Well, because yes, if people is named Funk. Yeah. But with a C, or an R. Okay, so these are the things which you need to install on your computer. So please go ahead and install. If you have installed everything, that's good. Make sure that notice in your path that everything will work correctly on your machine. So you can enjoy this workshop and you don't have to have to struggle. We're gonna walk through some things, so please you won't be in a hurry. There should be plenty of time for you to install these things. So once again, aka.ms.runSWA.
Now, there's great news, and that is that for using Azure, you will not need an Azure account. Nope, you will not need an Azure account. You will not need an Azure free account. Why not? Well, because there's this thing called a sandbox. And this is really great because this makes you able to just log in onto our Microsoft Learn website and take our services for desk drive and run through some workshops we have online there. And you can just, at your own tempo, go through those workshops and really try our services out. Great stuff. That's the best way to learn. Make mistakes, break things, test things out. Well, they say I have to do this. What if I do it a little bit differently? Well, or I read something else. Well, let's try that. So that's perfectly fine within the sandbox accounts. So these sandbox accounts, this is a fairly easy one to do. But you have to take into account a few things. So if you go to our website later on in the workshop, so you can find the link at aka.ms slash RunSWA, you can sign in on the top right of your screen. When you sign in, there might be depending on if you ever logged in into the website and there are some cookies, you will have different screens. But the most important thing is either click the use another account button or sign in options. So when you sign into our website, it is important to make sure that you use another account or click sign-in options. When you do that, you can choose a way to sign in.
4. Signing in and VS Code Features
5. Getting Started with Azure Static Web Apps (Cont.)
I said, I have already done this. And so what you end up with is within your GitHub account, you will have a new repository given this specific name. Yes. And about the names, please use the names as suggested in the workshop documentation. And why is that? Well, somewhere along the lines. Well, you might be copy-pasting something. Name will be different and then it will be fairly uneasy to debug that. So, if you use the names, which are suggested, you'll be good. For sure, yes, yes indeed. So, in the next step, so once you've created this repository, what we'll do is we'll clone this repository locally and we'll actually run the application on your local machine. However, I'm going to deviate from that a bit in this workshop, kind of to show you another nice feature of GitHub which we all like. It's called GitHub Codespaces. So, what GitHub Codespaces allows me to do is open this repository in a cloud-based development environment. So, I'll actually have a VS Code developer environment running within my browser. So, how do I do this? Where typically here, you would have the clone functionality here. You would be able to clone your repository from your clone link. If you have access to the Codespaces which is currently still in preview, we have a wait list, so you can register yourself on the wait list. You can open this repository using Codespaces. And so I have one open here if I click on that one. It will actually open VS Code in the browser. This is what you'll see here. It's authorizing to my Codespace environment. If I want to, I can actually connect this cloud-based developer environment also to my local Visual Studio Code environment if I want to. In that specific setup, then you would actually be coding against a cloud-hosted developer environment. So, this one we can remove. And so what you can see here is basically just VS Code, but it's not running on my local machine. It's running in the browser. But still you have all of the functionalities of VS Code as you know it on your local machine. So, you can do, you have your search. You have here your source control functionality. You can have your running and debugging functionalities as well, with like variable watches. You can have your watch variables. You can have your call stack. But also you can have your extensions here. So, right now, I don't have any extensions installed. But what I'll do in just a couple of minutes, I'll install the static web application extension, which you've probably installed already yourself as part of the prerequisites. And so what we can do here is we can start looking for static web apps. This is what I'll need, the Azure static web apps. And actually, I can just install this. So, it's installing that extension in my cloud hosted environment, just in the same way as it would do if I were to run a local instance of VS code.
6. Creating Code Spaces and Running the Application
You can create custom code spaces with pre-installed extensions for your specific project, saving time and avoiding dependency issues. Templates allow you to start with a clean project, making it easy to work on a certain project. Next, we'll install the dependencies and run the application on our local host web server. The application is running in a cloud-hosted environment, and port forwarding allows us to access it through a forwarded link. However, the application is not yet loading data as there is no API behind the scenes. We'll address this shortly.
And so all of this, and what's more is you can actually create your own custom code spaces which have already, for your specific project, all of the extensions that are needed, they can be pre-installed already. So you don't need to kind of go through and install them each and every time. So that's kind of nice as well, and very welcoming experience if you have somebody that contributes to your open source project and that wants to run it. Well they can actually spin up a code space and you have already pre-configured everything, all of the dependencies, all of the necessary extensions are already installed. And you can just get going in just a matter of minutes rather than having to figure out what do I need to install and how do I need to configure all of this. Yeah we're ending up in the dependency troubles we all know and never miss when we don't have them.
Also like what we skipped a bit on is what you did is earlier is you actually created a template. You used the template for the repository. So templating, you can compare it to cloning a repository but one of the advantages at this moment is that it will not copy the history. So you will actually start out with a clean project. So no commit history or anything. So this is a real easy way to start working off a certain project. That expectation is that this will have well many more functionalities in the future but this is already like really useful when you are doing work based upon a project you can just then play this and that's a really neat feature. So this is why we are not doing anything else. We're not not cloning or anything. We're just making a template. So what we're gonna do next is so we have our source code now available in our environment. And so we're going to install, run the application. So first what we need to do is we need to install of course a dependency. So what we'll do is we'll go to the React subfolder because here where our React application is sitting and we'll do an npm install to get all the dependencies for our project. And then we'll do an npm run to get the application started and be able to run it on our local host web server. So as you can see here, again, I'm doing all of this in my cloud hosted environment. So my terminal session, it's just a Linux terminal is just running in my browser, but it's running on a cloud hosted kind of a virtual machine, actually. Oh, maybe one thing to mention, you can actually specify which type of code space virtual machine you want. So if you start a code space, you can actually configure whether you want a two CPU or a four CPU machine to kind of host your cloud environment. And there we go. So we've done our npm install and let's clear this one and let's do an npm run to get it. I've been running. There we go. What did I? Yep, we got this one running, our npm. Ah! npm run starts or do an npm start, of course. So here's to either having start as a default. Okay. So what you see here, our application has started and a nice little feature of Codespaces is that actually, when you start the application and expose something on local host, actually there is port forwarding happening. So you can actually open this application by clicking on this forwarded link and actually it's going to link automatically to that local host sitting on our Cloud hosted environment and open up our shopping list. So there you go. So with that, we've kind of started our application now. It's running on local hosts. However, it's not yet loading any data because there is no API sitting behind the scenes. So we'll work on that. So that's coming up in just a couple of minutes.
7. Introduction to Azure Static Web Apps
We'll use Azure Static Web Apps to host our static front-end application on Azure. It provides a platform service that takes care of hosting APIs, static content, chorus configuration, and load balancing. This integration simplifies the process of creating a highly available web application. In the next lab, we'll add the backend part of our application.
Okay, so all of this is basically just getting our application source code and run it locally. Of course, what we want to do now is, well, the whole premise of this workshop is to host this static application, this front-end application on Azure. And so we're going to use Azure Static Web Apps for this. And so with Azure Static Web Apps, and let me, oh, there we go. I'll show this in just a couple of minutes. So as mentioned, what Static Web Apps gives you is this kind of this service, this platform service, allowing you to host static applications and taking care of all of the underlying plumbing for kind of hosting APIs, hosting the static content, doing like chorus configuration, doing the load balancing if you have multiple instances running. They see all the nitty gritty stuff you need to do to have a highly available web application up and running. And so this is what you all get integrated with Azure Static Web Apps. And kind of integrated APIs that will do in kind of the next lab where we will be adding the kind of the backend part of our application.
8. Configuring Fallback Routes
Azure Static Web Apps supports hosting static web applications using frameworks like React. When navigating to URLs in a static web app, there are no actual pages or page refreshes. Instead, the URLs are used for routing within the single page application. To configure a fallback route, you can specify in the configuration that the application should route to the physical index.html page.
Okay, and so this information and this thing, which is mentioned here in the workshop description is where we actually go into a little bit detail of configuring fallback routes. So Azure Static Web Apps really supports kind of hosting static web applications using a number of frameworks, like for example, React. And so one of the things with a static web application is that if you navigate to a URL, basically you get, well, so to speak these fake URLs, which navigate into sub pages of your application. However, those application links, those URLs, well, they don't actually exist. They're just a way to route within your application. So you don't get a page refresh, as you would have with a traditional URL if you can navigate to a different page, you get a full page refresh. With a static web application, of course you don't have that full refresh. It just is a way to route within your single page application. And so what you can do here is, configuring a fallback route is whenever there is a link that you, a hard-coded link that you provide and that you navigate to, using this fallback route, you can actually specify in configuration and we'll see where exactly you need to put this. You can configure that your application is going to route to the physical index.html page.
9. Creating an Azure Static Web App
To create an Azure static web app, you can use Visual Studio code extension, Azure command line interface, or the Azure portal. The portal provides an overview of hosted static web applications, including the URL to navigate to. The source code is stored in a GitHub repository, and a GitHub action is used for continuous deployment. In VSCode, navigate to the Azure extension, sign in to Azure, select the subscription, and grant access to the GitHub account. Specify the name and location of the code within the repository. Depending on the framework, the build output may be stored in a different subfolder.
Okay, so this is kind of some background into Azure Static Web Application. So if you go to the next step, this is where you will find this link to sign into the Sandbox environment. So here at the top, you can actually see sign in to activate Sandbox. This is where it will actually give you that your personal Azure subscription in which you can do all of the Azure work. And so where you will have a dedicated subscription for you, which you will then link to from within VS code to deploy your application into.
Okay. So what we're going to do now is create. That's the first step, is we need to create an Azure static web app within Azure, and there's different ways to do so. In here, in this workshop, we are using the Visual Studio code extension to create this Azure Static Web App. So what is nice is that you can stay within kind of the environment of obvious code to create these assets in Azure. The other way would be to either use the command line, the Azure command line interface, and just type a command line command just to create this specific resource within your Azure subscription. Or you could do it as well through the Azure portal. And let me quickly show you what the experience there is. If you go to portal.azure.com, let's just go through some logging in. It takes a couple of redirects. Before you land into, for me, because of my organizational account, it takes a number of redirects. So there what you can do is you can create a resource, just for example here, a Static Web Apps. Go here, I already have a number of Static Web Apps available. That's me take an existing one. And so in here, what you see within the portal, you can actually see kind of the overview of where is this Static Web Application hosted. So it is hosted in my specific case here in Western Europe. And it has a URL, which you can navigate to. So this is going to be your URL to navigate to your application. As mentioning new that the source is actually living in a GitHub repository, which is where it will find the code that you have created in the first step of this workshop. And so we'll have a GitHub action that runs to deploy in a continuous deployment fashion, all of the changes from your source into this specific environment. And so in here, you can actually manage your static web applications. So I said we're going to use VSCode. And so what we're going to do here is in VSCode, you can navigate to this Azure extension. So in here, we have the static web apps preview section. And so first we need to sign into Azure. So signing into Azure, it will ask you to connect to an Azure subscription. And so as you have your subscription created through the Sandbox environment, you will be able to choose that specific subscription. In my case, I'm using my own kind of internal subscription. So I'm choosing my account here. Here we go. I can now close this one. So now my VSCode environment is linked to my Azure subscription. And so we're going to create a new static web app. So we click this plus button. And so first I need to select my subscription. So which will be my Azure internal subscription. The next step that you'll need to take is, as said, static web application, stakes the code from a GitHub repository and it deploys it into Azure. So we have already given it the Azure subscription information. So now we need to give it access to connect to our GitHub account to create a GitHub action and to be able to deploy the source code from GitHub all the way into Azure. So we need to give access to this extension to our GitHub accounts. So this will give another extra GitHub approval flow. So it's going to authorize. There we go, I can now close this one. So we need to give it, yes Suzanne. And this is basically everything you need to do. Yes. To set it up like this is not everything you need to do, but everything you need to do to at least set this up. Yes. And so let's take a name here for our static web application we're going to specify in our specific case, we're going to specify the custom option because that will kind of show you a number of configuration parameters that we can specify. Because something that's special in this specific repo is you might be tempted to choose react here. However, our GitHub repository contains the code for vue.js, it has react, it has svelte and so on, all within the same repo. And so if you take this one, well, it's going to look in the root of the repo for the code of that one. However, in our case, the actual code is sitting in a subfolder of our repository, hence why we do custom. So we're going to specify where our code is. And so it's going to be in the react app. Sure. I'm not mistyping. So we have react app in there. In your case, depending on which flag you choose, it might be a different error. Yeah, so we enter on this one. Then as we don't yet have an API you can actually blank this one, let's say enter. And then again, depending on your framework that you're using, the build output is going to land potentially in a different sub folder. For react, this is going to be the build output folder. However, if you're using, for example, Vue.js you will have dist in there because by default Vue.js is building the output of its client side compile into the dist folder. So we can keep build in our case.
10. Deploying the Static Web App
Specify the Azure region for deployment. The closest region, West Europe, is recommended for preview. The static web app is created and the corresponding GitHub Action is created as well. The app is live and waiting for content. The GitHub Action workflow is created and the application is built and deployed. The basics of the app are up and running. GitHub Actions is an event-driven tool for software development lifecycle. The built and deployed job executes a sequence of steps, including source code checkout and building and deploying the application. The static web apps GitHub action takes parameters for deploying to Azure and connecting to GitHub. The source code is located in the React App subfolder and the output location is the Build folder. If a pull request is made, it will be closed as a result of the deployment.
Then you're going to specify which Azure region you want to deploy. So we'll take the closest one, which is West Europe, because Azure Static Web Apps is still in preview. You only have a subset of regions that are available in that list. However, as we go to general availability, that list will be expanded, probably to all of our Azure regions across the globe, which is quite an extensive list.
And as I was talking to it, I actually saw this notification popping up, which actually said that the static web application was created, and so that the corresponding GitHub Action was created as well. And you can see, we can open the GitHub Action directly in GitHub, which we'll do in just a second. But what we'll do as well is into our subscription, what we're going to do is, we can now see our My First Static Web App being created. And so we can, again, here, we can browse to our site. So we can open our static web app. You can see our static web app is live and it's waiting for content. And we did this without leaving, leaving the actual application we were using. So from within our IDE, we just created the surface and it's now up and running. But it created a bit more. So it's maybe fun to take a look at what happens at the GitHub side of things.
Yes. Because one thing which is weird is this is not the application that we expect to be there. That's not our application. This is not my shopping list. No. And so we can open basically our GitHub action. So we're going to GitHub.com to our repository, to the actions tab, which you can see here. And actually you can see that Static Web Apps and creating a Static Web Application has created a GitHub Action workflow. So we can click on this one to see the actual logging. So what is happening. And actually within that GitHub Action, there are two steps. So the first one is building the application and deploying the application to the Static Web Applications. And this is what you see happening here. So this is logging. So this will take a couple of, well, it can take a few minutes for it to deploy. So let me show you what exactly is in there. So it has completed quite rapidly now. So building deploying has taken a little bit less than two minutes and it's now. It always worries me when things are going faster than I expected. In this case, I didn't think. Everything is green. It's green. It's been deployed and we should be able to go to our website here and we can say a refresh. And lo and behold, we have our shopping lists up and running there. It will not show any data because, well, we haven't added that functionality yet, but the basics of the app, well, they're running. Yeah. So let's dive into that, into that, get up actions and let's see what was actually created there. Yeah. So, get up actions, it will help you with your software development lifecycle. It's an event driven thing. So, it means that after a certain event which will trigger it, you can run a service of commands and it basically looks like, it looks like this. So you will have a certain event for instance, when code get pushed and then you will do some actions. Well, hence the name, get up actions. Yes, indeed. So, each action is part of the job and can have a multiple steps resulting in the actual command which does something. So, that's basically the way it's set up. So, let's take a look at this one. So, let's take a quick look at this GitHub action. And so, as you saw, it was triggered whenever there is a push to either domain branch or if there is a pull request. Now, if this GitHub action gets triggered, it will fire off a sequence of jobs. And so, the first job that's going to be executed is this built and deployed job, which actually is going to do a number of steps. And the first step is going to be a checkout, which is actually pulling down the source code on our built agent. And so, this is the first step. And then the second step is building and deploying. And for that one, it's actually using a GitHub action, which is provided by the Azure team, which is to deploy a static web application. So, as I said, it's still in preview. And so, this static web apps GitHub action takes a number of parameters, which you can provide with this with, kind of keyword. And kind of important there is it's going to have an access token to deploy to Azure. So, it needs to have that secret to connect to Azure Static Web Apps. It needs a token to connect to GitHub. And then, actually what are the important settings is what we provided through Visual Studio code in creating that static web application is where is the source code in our GitHub repository. So, it's sitting in the React App subfolder. Where is the location of the API? So, we kind of blanked that one because we don't yet have an API. And then, the output location is where, for our framework, the actual code is being deployed. And so, this is the Build folder. Okay, and so, in the second step, if we have done a Pull request, the second step will be to actually close that Pull request as a result of the deployment.
11. Deploying Source Code to Azure Static Web Apps
This section provides an overview of the GitHub action used to deploy the source code from GitHub to Azure Static Web Apps. It explains the different events that can trigger the action, such as commits, issues, pull requests, or webhooks. The section also demonstrates how to open the Azure portal for the Static Web application, providing links to the web application, source code, and GitHub action. It mentions the ability to configure application settings and custom domain names. It concludes by asking for feedback from the participants and addressing an issue with connecting to the Azure portal from VS Code.
Okay, so this is using, again, the static web apps deploy, and it has a specific action to be able to close that Pull request. Okay, so kind of, this is kind of a quick, quick overview of our GitHub action that will take the source code in GitHub and actually deploy it to Azure Static Web Apps, the JSL service. And it's kind of multiple events, which it listens to. So it can either be a commit or an issue or a pull request or maybe some webhook. It can be many different things triggering this.
Okay. So, going through our lab, so we have basically gone through all of the different steps. And so, we've kind of looked at the GitHub Action. One thing which you will find as well in the workshop description is here, this open in portal, which allows you to open the Azure portal specifically for your Azure Static Web application. So let me quickly show this one here. If you right click on the Static Web application, you can say open in portal, and that will actually open the Azure portal specifically for your Static Web application. So it's navigating there. Which is of course always funny with our internal accounts because they ping-pong a lot, but eventually it will open. There you go. There we go. And so here we have it, and it has the link to our web application. It has also the link to our sources, which is sitting on GitHub. It also has the link to our GitHub action. And so the direct link into our GitHub action workflow. Okay. Also you'll see here other settings that allows you to kind of configure some application settings. TrueDeconfiguration tab here as well. You can configure custom domain names for your application as well as functions to represent basically the backend APIs of your application. Which in our case, we don't yet have those functions. But we'll see them appear as we go to the second lap. Surprise, surprise. Yes, okay. So we've gone through the GitHub action. We have our end-to-end flow now set up. So as we make changes to our application, automatically, those changes will be picked up and will be deployed in our static web application. Okay, so any change, any push will trigger the GitHub action will actually trigger the deployment into Either. Okay, I think with that, we've come kind of to kind of the end of this first module. And success, lo and behold, that was quick, without. That was really, really fast, if you take into account all the things happening under the hood, like a lot of stuff. So I'm wondering, how is everybody doing? Are you following along? Do you run into any troubles? Are you good? We also like to hear when you're good, when you're on track, you also have a half-functioning shopping list app. Or maybe you even are working ahead a little bit, maybe your app is already working. Yeah, do we have any feedback from people? Yes, Oleg is not able to connect with the subscription from VS Code. And so is that the connection to the Azure portal? Or is it not working at all to connect? Because when you, when you, it's asked select subscription. Okay. Does it show the subscription? So maybe it's good to run through the steps again. One time, Nick. Yeah. To show. Yes. Because it, it went really fast. So I can imagine that was... So yeah, let me quickly show you here. I was wondering if I could, there we go. Oops. Not too fast. So what we are doing during this workshop is we use the Sendbox. Yes. The Sendbox account, which you create on Microsoft Learn. So if you are here at the top of the Microsoft Learn module, which we are following along with, you can click sign in, there you have to click and you have to log in with your GitHub account. And that is basically the account you will also use to activate the Sendbox. So we are not working with any Azure account at all. We are working with a GitHub account, which is conveniently linked to Azure by creating the Sendbox. As you see... So now, well... It's multi-factors. This is always a bit exciting. Yes. Authenticating. Yep. Proving... This is why I made screenshots of that one. Yes. Because I'm not to go through all the hurdles of... Oh, yeah, for sure. So now Nick is logged in with his GitHub account.
12. Activating the Sandbox and Alternative Method
To activate the Sandbox, you will be asked for permissions. Review them carefully, but for brevity, click Accept. The Sandbox provides all the necessary permissions and allows you to work for free for a limited time. You can create up to 10 sandboxes a day, each lasting about four hours. Now, Nick will demonstrate an alternative method using the portal.
And if he now activates the Sendbox, then it will normally ask you for some permissions. There we go. Some reviewing permissions. Which is good to always review. We advise you to read everything. For the sake of keeping it brief, we'll just click Accept. Yes. Because we trust those people. Absolutely. Yep, we're not biased. There you go. And it goes through all of the authentication hoops. Federating, connecting. I hope it's not clashing with all of my other subscriptions. There we go. It's taking a sandbox. It has all of the permissions. So this should be. And the reason we are doing this is to primarily create the Azure account. So we can work for free on our sandbox. Yes. And we can create like 10 sandboxes a day. And it's sandbox will be a live for, I think about four hours or something. Maybe three, don't pin me down on that one. I'm already happy if I have one half hour to work in my sandbox. So. So it's four hours? Four hours, Yeah. Well, good, I passed that one. So this is basically what you will have to do. Now Nick can also show you, how we could use this without using the IDE. So if we could either go to the portal, that would be a way to.
13. Signing into Azure and Creating Static Web Apps
To sign into Azure, open the portal and search for Static web apps. Connect Visual Studio Code to your GitHub account. Choose the Conscierge subscription and enter the details for your static web app. Select an existing resource group and specify the location. The static web app will be created in your subscription. You can create multiple static web applications connected to the same GitHub repo. GitHub actions will be triggered for each deployment.
Oh, wait. Now, wait a second. I wanted to, to, to, to, to, Sign out again. Where is the sign, Azure sign out. I think it's in here. Can you see it? No. I always sign out, but I never signed, signing in or sign out. So sign out. And that. That's a great suggestion to restart VS Code when you have any trouble with authentication. So we're going to sign into Azure. Let's see. So what we are doing right now is showing you the other way which is just using the portal. Now if you open a portal, you are able to search for Static and then it will show the Static web apps. Yeah. So now I'm just connecting Visual Studio Code to my kind of account, which I used for my GitHub account, which I use for signing into my sandbox. So let's see if that works. It does not interfere with a multi-factor authentication. Nope. There we go. So I have here this Conscierge subscription, that's kind of a tongue twister, which does not yet contain any Static Web applications because I have not yet created one. And so this Conscierge subscription is the one that you get assigned as part of your sandbox environment. And so in here, I can actually connect to this Conscierge subscription. Call it, I think it's My Static Web App. Enter. We'll do custom. We had the React app as the application code location. It has remembered this, so the API we don't yet have. And I enter. Build is where our output is sitting. And then we can say Western Europe. So then it's going to ask me, I don't have permission to create a resource group in this Conscierge subscription. So I want to select an existing resource group because this sandbox environment has been set up with limited permissions. So you get kind of a resource group in which you are kind of the owner. You don't get the ownership of the full subscription. And so I'd select this pre-created resource group. This Learn something. So now it is creating this static web app within my subscription. Now, one thing we'll have in here is that if we now go to our GitHub actions, I have now actually created two static web applications connected to the same GitHub repo. Which allows you to basically, with the same sources, deploy to two parallel static web application environments. So as you see, it has kicked off two GitHub actions and two shared workflows. One which is connected to my sandbox environment, one which is connected to my own kind of Microsoft Azure subscription. And this is what you see happening here. Okay, there you go. So I hope kind of going through how you use this kind of concierge subscription has helped.
14. Deploying Azure Static Web App from CLI
To deploy your Azure Static Web App from CLI, you will need Azure CLI. Another option is to connect to the Azure Portal. You can also use the Azure Cloud Shell, which provides access to the Azure Command Line interface. Multiple ways are available to achieve this, including using Terraform. If you have any questions or need help, feel free to reach out. The next module focuses on publishing an API to a static web application using Azure Functions.
Who had this problem, if the problem was resolved? Yes, I see at least one person with a resolved problem by restarting. So there was also a question. So how can I use this without IDE? So I pasted an instruction on how to deploy your Azure Static Web App from CLI. The only thing you will need is Azure CLI. Yes. That's one option. The other option is you can go to the Azure Portal and connect there. But then you can also do either the Azure CLI because you can just open that from your portal, which is quite nifty. And maybe you can show that, Nick. And the other option is just to do the, well, the next, next finished experience, like I like to call it. And that's just looking up the surface in the Azure Portal. And there you can create it and you get the questions, you get the questions and you just have to complete the steps there as well. So there's like multiple ways to, of course, achieve this. Maybe, maybe you want to use Terraform, that's also possible, but it's a bit overkill for this workshop. But we encourage you to experiment with everything. If you run into a problem or you have questions or need documentation, let us know. We are here to help you. So what I've connected to here is the, what is called the Azure Cloud Shell. So you can go just to shell.azure.com. Or within the Azure Management Portal, you have this little icon here sitting on the top right hand side, which shows Cloud Shell. And so in here, you have access to basically the Azure Command Line interface, which conveniently is called AZ for Azure. And for example, you could say, Azure Group List. Let's do, put in table format. And it gives me basically all of the resource groups that are available within my subscription. Yeah, and if we would add this static web app on CLI, which is of course something you maybe would like to do or automate or anything like that, that will be the command to create a static web app that's AZ-static-web-app-create. Then you'll just add a name. If you do az-help, you can actually see here all of the different commands that are available. So if you want to create a Postgres db and are specific if you want to create a static web app, it would be AZ-static-web-app. And then you have to actual sub-command which is create. Then you give a name and a resource group. And what you will do is just provide your GitHub link like you can see in the help output. And you just have to make sure that it's created in a certain location. For instance, like Western Europe or the people maybe on the U.S. side. You know there's a lot of regions. But still few static web apps is available at this moment because of the Preview. And the other thing is you might need an access token. You can supply that as well on the same command line command. So there's multiple ways to achieve this. Now let's move on. I see that the problems are fixed. So we're good to go. Okay. Perfect. Let me close some of these here. There we go. We don't need this anymore. Okay. So we'll go to the next, our next module, which is publishing an API to a static web application. So I'm going to open this lab here. There we go. And again, here, what is the objective, is to, well, to our static web application add a backend API. And so our backend APIs are using an underlying service within Azure, which is called Azure Functions. But we go to the Get Started. So Azure Functions is our kind of serverless offering for you. So I can actually, let me remove some stuff here. And so first we need to, again, create a repository from our template. And so we can again open up this template generation. So we need to copy this name here. And actually what you'll get is, it will tell you that it already exists. Yeah, Web App with API, shall I call it. I'll call it as a private one. Now, one thing is that the name of the repository in this specific case in our workshop does not really come back as such. So giving it another name should not give you any issue as such, if you're going through the steps of the lab. So we can create our repository. This should take just a couple of seconds. And actually the template will have the same shopping list application. However, it will already have a number of the backend APIs pre-created for you. So you will see here this folder sitting here, API starter, which is actually where kind of the base set of backend APIs are available for you. So let's close some of these pictures here, these tabs here.
15. Adding API with Azure Functions
We'll add an API to our existing web app using Azure Functions. Azure Functions supports multiple languages. We can connect Azure Static Web Apps to Azure DevOps repositories. We'll install dependencies, run the app locally, and ensure it works. We'll create a new Azure Static Web App for our module and configure it. The GitHub Action is triggered, and the app is deployed. We'll review the GitHub Action and check the static web app and API in the portal.
Yeah. Now while my code space is starting up, one thing so, so far we've kind of focused on, or we've shown you kind of, you take the code from a GitHub repository and deploy it to Azure Static Web Apps. Quite recently, earlier this month, we actually released the preview of connecting Azure Static Web Apps to an Azure DevOps repository as well. So where right now we're going to GitHub, but just as well, if you are already using Azure DevOps, you can now use those repositories as well as kind of the source for deploying to Azure Static Web Apps, which is kind of a nice add-on. And quite some people that were using DevOps already were kind of waiting for that functionality to arrive.
And so now we're going to back to our React app, npm install to get all the dependencies in, and then we'll run it locally as we did it before, just to make sure that everything works fine. And if we browse, we'll still have that loading application. Here we go. So one thing which I need to do here, does it have the static web apps preview? It does not yet have it. It does have it, okay, good. And one thing which we'll need to do then as well is make sure that we have the Azure Functions runtime tools because we want to run this application locally. And so Azure Functions allows you to kind of have the functions runtime also running locally on your laptop. And hence why if you want to run and debug locally you will need that functions runtime on your local machine. So we can now do an NPM start just to make sure that everything works fine. So the application starts up and you can actually see that automatically it is also showing that localhost link here mapped to our cloud environment. Okay. Yeah, and if you are like, Oh, I forgot to install that Azure Functions locally I put the link to the resources in the chat. So yes, You will very quickly discover that you don't have it. No. Yeah. Okay. So we can stop this one. And so again, what we'll do is we'll create a new Azure Static Web App for our new module here. And so, again, we're going to our Azure extension. We need to sign into Azure. So I'm going to use, let's use, again, my own subscription. There we go. Into our, now create a static web app to my internal subscription it wants to connect to GitHub. There we go. Going through some authentication links. So, let's give it a nice name and I think in here, it is my static web app and API. So, my static web app and API, let's take the correct name. Go, we do enter. Again, we'll have, uh, we have, we just have a main branch. We'll need to select a location. So, once again, we are going for custom. Why is that? Yes. Well, that is because we ship multiple frameworks in just one repository, so we have to point to the React app or, well, whatever your flavor of the day is. Yes, yeah. QApp or, uh, Svelte app. So, in here we're going to skip, still going to skip the API location because we don't have the API yet and that will kind of show you how we can adjust it afterwards. So we'll just leave it blank and do enter. We're going to use, again, the built output folder, which is the default for React. Enter, choose the location, so Western Europe. And again, it's up there deploying and creating this static web application. It's kicked off this GitHub Action already. So we'll leave it up and running. And so we can grow through all of this, reviewing the GitHub Action. This is the stuff we did before. So if you want to, again, you can enter here. Again, just refresh and see that we now have our static web app and API. I'm just going to show it in the portal, open it up. This is the same experience that we had in the first lab. So this should be, well, probably a bit smoother than your first experience. So this is now the second time we're doing this. And then we'll go to the experience of having our backend APIs to our shopping list so that we have a real shopping list showing some information and allowing us to update and make modifications to our shopping list. So we can see that we have our static web app and API. It has a generated URL, I think for the time being, it's still empty because our GitHub action is still running. So we'll give it another minute to complete. Yes, and this is pre-generated. You can add your custom domains to this. That is not a problem.
16. Adding APIs with Azure Functions
Azure Functions allows you to build serverless functions using any language. For a shopping list, we'll need four APIs: get, post, put, and delete. The APIs will have endpoints hosted within the same static web application. The source code of the functions contains metadata and configuration, specifying the triggers and routes. The implementation of the functions can be written in different languages. The functions can be triggered by various events, such as HTTP requests, message queue events, file drops, or time events. The next step is to add the functions to the code and create a separate branch for the changes.
Indeed, yeah. So Azure Functions, as mentioned by Suzanne, is your way to build these serverless functions using any type of language. And so what for a shopping list, we'll need actually four APIs. So the first one is, so using different HTTP methods, we'll have a get, a post, a put, and a delete method that will support to have the corresponding actions to our shopping list. So getting them, updating them, creating a new one, and deleting one. And so within Azure Static Web Apps, if we add these APIs, the endpoint for those APIs will be your hostname. So your hostname that has been generated, so in this specific instance, it's going to be thankfulhill and something dot azurestaticwebapps.net. And the APIs are going to have slash API slash products as your endpoint for your REST APIs. That will be hosted within that same static web application. So they are co-hosted with your static content for you, but they are basically created using Azure functions underlying under the hood.
Okay, so if we look at the source code of those functions, you can actually see in this API starter, as mentioned, we have these corresponding methods. So if we go to, for example, the products, let's say the delete one, we go to function.json, you can actually see kind of the metadata, the configuration of that specific Azure function for you. And you can see there, this function is being triggered by an HTTP request. So it's an HTTP trigger. functions can be triggered by all kinds of events. So either it's an HTTP request. It could be because of an event coming into a message queue, it might be because there is some file dropping on storage. Many different types of events can actually trigger a function. It could be a time event, or it could be a message landing in a queue as well.
17. Creating Azure Function with HTTP Trigger
To create an Azure function, you can use the Azure functions extension for VS Code. It provides the functionality to create new function projects and different types of functions, such as HTTP triggers. The default implementation of an HTTP triggered function can be used in production environments.
And so we need to have the Azure functions extension for VS Code. So let's see if we have this one here. So we go to our extensions. Functions. There we go. So we don't yet have it. And if we do, install. Basically what this will do, it will give us the functionality within the VS Code to create new functions, create new function projects in our sources. Is this mandatory? No, this is not mandatory. You do not have to use this. It will just make your lives a lot easier. Yes, so if we go to our command palette by doing F1, we could say, Azure function, and then we could say create function. And then you can specify which type of function you want to have created. And you want to have an HTTP trigger, time triggered, and so on. So in our case, we want an HTTP triggered function, and our name should be, let me copy it so I don't make any typos. Products get. The space, we do enter. We will have our anonymous authorization level. There we go. So that's it. It has created a function now. And as you can see here, we have the products get folder. So we have our kind of configuration file for our function. And also it has kind of a default implementation of an HTTP triggered function, which is just going to show you some hello with the name, which has been posted. This is super useful for production situations. Yes, this is kind of the must have function. For your production environment.
18. Configuring Function and Local Settings
Okay. So one thing we need to specify in our function configuration is, well, we don't want this to be linked to our post HTTP method, we just want to have it linked to our get method. And in addition, we need to specify the route, which is basically going to be products, because we want to go navigate to our URL slash API slash products to get the list of products returned to us.
So, now we have configured our get function. Now, one thing you'll see here in the lab is configure course locally. And what is important is the word locally because Azure Static Web Apps, and Suzanne mentioned that before, is the whole configuration of course, all of the plumbing to connect basically your static front end with your APIs and the course that is required for that is done automatically for Azure Static Web Apps when you deploy it to Azure. So, there is no configuration that is needed specifically and explicitly for you to get that to work. However, when you're running locally, or you're not running within kind of the managed environment of Azure Static Web Apps, you're just running on your local machine. And in there, you are running into issues of course, because your front end is running on port 3000, local hosts for 3000, which is by default the one that's used for React. But your functions, your APIs are running on port 7071. And so you will hit there a course issue that your front end cannot call directly into local host 7071. So you need to configure this explicitly within a local file within your local environment. So in our local settings, so this is what we're going to do here. So in our API folder, so for our backend, we are going to have a local.settings.json file. So this file is explicitly excluded from your Git repository. So this is not part of your actual application. It's just used locally for developer purposes. And so here, we're actually specifying the course configuration for our Azure functions to allow requests to come from localhost port 3000 to let them through.
19. Running API Locally and Deploying to Azure
To run our API locally, we navigate to the API folder, install the dependencies, and start the Azure functions. If the functions runtime is not installed, we need to install it manually. The functions are hosted on port 7071, and we can connect to the GET API to test its functionality. After confirming that the API is running locally, we open a new shell and navigate to the reactapp folder. We install the dependencies and start the frontend application. The application successfully connects to the functions and loads the data. We can edit items in the shopping list, but the application is only accessible locally with authentication provided to GitHub. To deploy the application to the Azure static web application, we need to update the API location with the correct folder.
Okay. So now we've done all of this, and so we need to be able to run our API. So I'm going to my terminal and I'm going to the, let's clear this one, going to the API folder. And what I'm going to do here is now do an NPM install first, make sure I have all the dependencies, there are everything is installed, and we should be able to do a func start from Azure functions start.
And lo and behold, it says func commandNotFound, which is because I don't have the functions run time installed. And so what I need to do is I need to do an NPM install of, and the link was in our set of links that provided. I did give a heads up install that. Yes, and I didn't do it. But at least that answers the question on the chat does the extension install the portals? No, it does not. You have to do that yourself and it will integrate with that. It will add some neat functionality to test and run your functions locally without leaving your ID or, you know, hassling around. Yes, or having to deploy to Azure each and every time you want to test something. So, that gives you kind of that local development environment. So now, if you do func start, it's going to pick up and detect that we have four functions. And as you can see, they are hosted on port 7071.
And so we can connect to, for example, the GET API. So this is just local host 7071, just to see if our GET function actually works. And lo and behold, we have our three products being returned from our REST API. We could discuss what is locally in this case. Because as you see, this is a real serverless example. We're running from code spaces. It will do some automatically ports forwarding for you. So just get that local experience. Yes, you can actually see here in the ports kind of tab here. You can actually see all of the ports that have been forwarded for you to connect to. So with that, we have our API running locally. We can now check if our frontend application can connect to that API. So this is what we're going to do next. So we're going to open a new shell here because we'll leave the other shell running with our function. And so if we go to the... Where do we need to go to? To the reactapp folder. I'm doing npm install. That was something weird. I can run this workshop like many times, like for each framework and have a new workshop. Yes. That would be weird. Yeah. No. So we do an npm install and then we do an npm start to start our frontend application to react. And now our react frontend should be able to connect to our functions and it's loading the data. And yes, we have all of our shopping lists available now. And so we can edit items. We can say for example, the quantity. No, we want 10 strawberries. Chocolates. Yes. Yes. Add one. It's called chocolate prescription. Wow. That's great. That was just what I was thinking about. So, but now if I go to this link, I'm able to edit this. You mean this link? Yeah. Yeah, you can try. I could just add some of my stuff to your list. Yeah, but unfortunately that will not be possible. Because this is running on my local host. It is exposed to this URL. However, there is authentication. So all of these URLs are not available, are not publicly available. There is authentication provided to GitHub. So these URLs which have been port forwarded are only available to you. No risk in exposing your shopping lists in your development environment. Well that's good to know. Yes. So we have run the web application frontend and we can see that it has connected to our IPIs. So what are we going to do next is now, well all of this was running locally. So we need to take again the next step and deploy it to our Azure static web application. So this is where we had this API location which we left blank for the time being where we'll need to update it with the right folder.
20. Deploying API Changes and Troubleshooting
In this part, we specify the API folder and add the get function. We commit and push the changes to the remote repository. We create a pull request and merge it. The GitHub action is queued and the application is deployed. We discuss the separate environment created for pull requests and the URL for the deployed static web app. However, the app is not loading data, and the cause is not yet determined.
Yeah, and so this is our API folder that we have used here. So we'll need to specify this. So we'll see how we do this. And so one thing, and I'll show that in a minute. So as you remember, we kind of put everything in a separate branch, in our API branch, which you can see here. And so one thing I still need to do is our get function, I need to add it here. And I'll say, add the get products API. So I'm going to commit it locally. And in addition, what we need to do is, we'll need to push this to our remote repository, all of this is still running locally. I'm going to do a push. Would you like to publish this branch? Yes. And would you like to create a pull request? I can do so straight from in Visual Studio, Visual Studio code, or we can do it as well from the portal. And this is what is actually shown here within the workshop. So I'll follow kind of the instructions from the workshop. This needs to be in github.com. My repository name, I think. And code it like this, I don't recall. What's the name, yes. Okay. So we had Push one minute ago. So we can compare and create a pull request. So our API folder, we're going to compare our API with our base, we're able to merge, we're going to create a pull request. There we go. There's no conflicts, and so we can now merge this pull request. It's now, if everything works fine, of course. And one thing you'll see here is it has queued our GitHub action, so our built and deploy, and actually it will actually close this pull requests upon completion as well if needed. So we have created our pull requests. We can go to our actions. So we can see that our API change, our commit of our new API is now committed or is now created. However, and this is one thing which you will see, and one thing which I didn't do, well, you'll see the results of this in just a second. Maybe somebody has noticed already. If you know it, before Nick opens it, throw it in the chat what's going to happen here. Yes. Will they have success or not? Failure. Failure. Yeah, so this takes. We don't say failure. We say learning opportunity. It's indeed, it's a massive learning opportunity. Yes, these are just warnings, so it should be fine. So now it's doing the pm install. It's doing whatever it needs to, to kind of install and deploy the application to Azure Static Web Apps. There might be something we forgot to do. Yes. So if you know it, throw it in the chat, let us know. Do we have any suggestions already? Let me, not in this chat. People are you still there? Are you following along or struggling with the deployment? Let us know. If you know what we missed in our enthusiasm. Let us know. It's a little thing. Yeah. And so while this one is actually happening, so one thing I want to tell, I need to mention here is, and it's well-described as well in the workshop is, so initially in our first lab, we were actually deploying straight from or pushing straight to our main branch, which typically you don't do. You make your changes into as we did in a separate branch and then you create a pull request and then you merge potentially. But what we did was we made our changes directly to the main branch and that kicked off our GitHub action, and so it deployed to our production static web application. However, if we create a pull request, what static web applications is doing is actually creating a separate environment, a separate URL dedicated for our pull request. So it is actually that change that is sitting in our pull request is actually living or is actually deployed alongside our production environment, which is kind of neat because, well, your pull requests, well, it's only until you merge it in your main branch that you can actually give it the okay to deploy it into your production environment. You don't want every single pull request to automatically be deployed and being deployed over your current production environment, and so this is happening automatically. And so our application, or our URL has been, our static web app has been deployed. And so the URL, you can find it here in the log file. If I go here, I click on this one, we can actually see it here. And so one thing you'll notice is, it gets a URL which is slightly different in the sense that it has, here, there's minus one sitting there, which is actually the number of our pull requests in our GitHub repo. So each time you create a new pull request, you will get a new URL to deploy your application to. However, what you notice is that it's not loading our data. And so did we get why that happens? No, no. Okay, yes, you can. Don't be afraid to answer. There's still wrong answers. Your answer might not be the solution to the problem. That's okay. That is all fine.
21. Closing Pull Request and Updating API Location
In this section, we address the issue of the API location not being updated in the GitHub Actions workflow file. This causes the static web app to not know where the API source code is located. We explain the process of closing a pull request and how it triggers the GitHub action to close the environment within Azure static web applications. The separate landing zone is deleted, and the URL is no longer available. We also mention the availability of staging environments and the benefits of using Azure Static Web Apps for hosting web applications.
Perfectly fine. Yeah. And so one thing I'll do is, go back to my main branch. Just going to sync my main branch here. So, how's everybody doing? Are we still good? Are we on track? Do you experience an issue or have a question?
What is the close pull request job for in the GitHub Actions? Well, we can take a look at that, but it's to close the actual pull request. It's the end of the pull request process. Yes. So, we have an exit from an open pull request.
Yeah, let's scroll down. So, this is where the problem was. So, here in this code, I'm just opening up the GitHub Actions workflow file. And so, as you can see here, we did not update our API location. So, actually our static web app does not know where the API is living, where the source code is. And so, we need to make a modification there and put API there or whatever name of the folder you've given your API folder in our specific case, it's API. And so, if we now... commit this one... So, updates API and location in our GitHub. And if you can scroll down a little bit and in this GitHub action and yaml file... Yes. So, you can see that what happens... Yes. Is actually the pull request. Yes, so what happens is, if you close your pull request within... Do we have it still here in our... Wait, this is way too big. I scrolled all the way up here. So, we have our pull request which is still sitting here. It's still open. So, as long as that pull request is open, our kind of environment within static web applications is still there. So, that special URL that you get, which has this minus one suffix in the URL, that is living until you actually close your pull request. So, as soon as I click this close pull request, what is happening is that in our GitHub action is going to check what was the GitHub event name, so it is something to do with the pull request. The actual action that is happening on that pull request is it is being closed. What happens is this GitHub action will actually close the environment that is sitting within Azure static web applications. So, the separate landing zone that exists will be deleted for you. So, that URL will no longer be available when you close that pull request. And so, this is what's happening in this specific case. So, this one is only being invoked if you close the pull request within GitHub in your repository. And so, this one, I still need to commit. And I need to push it to the repo, which will trigger, again, a new GitHub action run. And so, we'll need to wait kind of a minute or two for it to update our website. And so, that one we can close. I think here, if we look at environments, so this is where you can actually see, if you go to the Azure Portal, well, in the actual detail of your static web application, if you go to environments, this is where you can actually see that you have this API branch linked to that environment. And so, you can navigate to it. And so, that URL to browse through it, so this environment will only exist for as long as that pull request is actually live, yeah? So, by default, if you're just pushing your changes to the main branch, you will only see this. There will be no, like, staging environments available to you, for your environment. But that's something you would normally, well, probably not do. Yep, you would typically go to, yeah, creating a new branch for a change, pull request, and then, yeah, review the change, was it okay? If yes, you merge it to your main branch. And only then, you will update your production website. Yes. So, we can actually browse to it and see if. So the fun thing is that, when you do that, it is not only that you will, it will tear down the environment. It will also, of course, initiate the deployment on your production. So. Yes. That's a few steps you just don't have to take anymore. Yeah, and again, this kind of shows you kind of all of the flexibility, that otherwise, if you kind of spin up your own kind of hosting environment for your web applications, if you want this kind of staging environment functionality, well, you'd have to roll all of that yourself, all of that automation, of spinning up a new environment if you do a pool request, tear it down when that pool request is being closed, all of that stuff you need to do and set up yourselves, whereas this kind of comes out of the box with Azure Static Web Apps. And now that we have functions, we can actually look at, oh, wait, yeah, they're not there yet, as it's still deploying, because it couldn't find it. This is where, basically, our four REST APIs will be shown. And so let me quickly go back to our GitHub repo to see status. Okay, so we have our API location. We just missed it, I guess. Oh, wait, yes. This is your... Is it loading? What did I do wrong? Must have missed something. Let me quickly come back to it. Thank you. Am I looking at the wrong one? So we have our API. This one, it's sitting in the API folder. Let's quickly did... Let's see our API.
22. Checking Logs and GitHub Actions
Let's look at the logs and check the REACT-App and API location. We're experiencing an issue with the API directory location not being found. It seems that the GitHub action is running off the main branch instead of the API branch. I'll make a quick change to the API branch and trigger a new GitHub action. By default, the workflow is only triggered by a push or pull request, but you can configure it to allow manual triggering from the GitHub UI. GitHub actions can be triggered by external events and can also be chained together. Let's check the output to see if the issue is resolved.
Let's look at the logs. Let's first look at REACT-App. We have our API location as API, so that should be fine. Let's look at the outputs. Yes, so we'll have live debugging here. Yeah. Build, deploy. I like this so much because everything is in one place. Oh yes, warning. The API directory location, API could not be found. That's, Did you by any chance refer to the main branch in which the API wasn't present? No, because actually the actual GitHub action is running off of that pull request, which is not the case. So if I'm not mistaken, I probably should have put slash API. That's probably where I, how did I come to think of it. I think it should be slash API. because yes, you're saying it is running off of and now I don't need to change this into the main branch, sorry. Oh wait, yes, this needs to happen here. Oh wait. So, yeah, I see what happens, I think. It is kicking off the GitHub action as a result of updating the GitHub Action, which is running in the main branch. However, there was no change to yeah, it has, of course, not pulled down the sources from the API branch because there was no change there. Hence, what I need to do is, okay, so this one is now up to date, I just need to make a quick change to the API branch. This is live, people. Yes, this is indeed live. Yeah, yeah, that's okay. So I'm switching back to my API branch. So anybody else sometimes confused about in which branch we're working, raise your hands? Yes, these things happen. Just email us. There we go. And we are in our API branch, then I can go for example, to the get the implementation. I'll add a space. Because space is not significant. OK. OK, um. Add space to trigger. Deploy. There we go, and then we push this one to a remote repo. And we love space. Yes. And that should trigger. A new GitHub Action. There we go. And now I should trigger it in the API branch, where the actual API folder is present. So, hopefully. Yes, it should be. One thing you'll... So there is a... Let me quickly show you one thing here. If we go to this workflow... I'll show it here. Actually, you see that our workflow is only being triggered by a push or by a pull request. So you might wonder, what if I need to kind of trigger my workflow manually. If you want to do so, you need to explicitly put that in your GitHub Action Workflow. So by default, that functionality is not in there. So you need to explicitly configure your workflow to allow for triggering your workflow from the UI. So while that one is still running, then I think I can actually show you if you create a new workflow here and say, set up a workflow yourself. It will actually show you because I see here. This is the part which I wanted to mention you here to allow a workflow to be kind of triggered straight from the GitHub UI. You need to just add have workflow dispatch to your GitHub action. And the on section here at workflow dispatch. And that will allow you to kind of triggered out that, uh, that GitHub actions workflow, uh, manually, uh, true to, uh, to the user interface from, uh, from GitHub. There are all kinds of fun use cases for this, because GitHub actions are designed for data & web apps. Biggest because GitHub actions integrate with a lot of different, uh, stuff. So yes, yes, you can, you can actually trigger those GitHub actions by external events as well. Uh, or you can have a workflow which is triggered by the completion of another workflow. So that allows you to kind of componentize, uh, or kind of decompose or maybe a massive, yeah. This sounds, if you start something like this, thinking about it on a Friday evening, it might, uh, escalate very quickly. Yeah. Like what, what could we like chain to each other? So let's take a look at, uh, the, um, the output of this. Yeah. If it's still not there.
Cold Start of Azure Functions and Q&A
The Azure functions experienced a cold start, taking a few seconds to load initially. However, on subsequent refreshes, they load immediately. This is a common occurrence and can be attributed to impatience. The goal of the workshop was to achieve this functionality. We also received questions about deploying Node.js applications to Azure and deploying them into containers. Although we didn't cover these scenarios in detail, we will provide links for further information in the Discord chat.
Oh yeah. There it is. So we can actually try now refresh even better. Oh yeah. This one, I'll come back to this one. Yeah. Why that way? No? Why I'm in my branch. What did I do wrong? Tell me, Susan, where did I, oh, let's probably say again, that okay. April three and yeah. Okay. API was found. Yeah. That's good. Oh, Wait. The only thing I can think of is, oh yeah. There you go. See we're just, this is a common problem. Yes. You probably playing stuff. Impatience. Luckily for us. So let's see. Doesn't really work. I can add chocolate again. Yeah. Yeah, certainly. Though I I'm starting to get in the moves for bits, it beats out, but it might be because of the time being six here in the wonderful Netherlands shining. Yeah. So there you go. So yeah, what you saw happening there was actually something we call cold start of. Uh, functions. So our Azure functions are API's had not yet been called. They've had not yet been invoked. Uh, so they need to warm up a bit. Uh, and so it takes a couple of seconds for them to load. And I, indeed I was a little bit impatient. Um, and so the first time you run it, it, it takes a couple of seconds, right? Whereas right now, if you just refresh the page, uh, it should load them immediately. So your function is warmed up. It's up and running, uh, and giving you the results. So immediately, um, exactly. And that's pretty much what we wanted to achieve in this workshop. Yes. We, we, we succeeded. Yes. So, um, anything else you wanted to, uh, share, um, Suzanne I think we had a couple of, we had a couple of questions at the beginning of people that wanted to see, uh, how do I take a node JS application? Cause here we've just deployed a kind of front-end application. Uh, how do I deploy node JS application to Azure and how do I deploy a node JS application into a container and then maybe to Azure? Uh, we've not gone into that scenario. Um, but we'll post some links, uh, I think in the. Well, we can't do it here in the discord because in the, in the zoo. Now we will throw it in a discord. Yeah. Um, just so you can, you know, um, We get, uh, and it doesn't get lost. So if you're tomorrow, you're like, I wish I remember that URL. We'll just place them this court. Um, that, uh, that won't be, uh, be deleted. There was a question on how to manually trigger. The answer is in the chats. It's a workflow dispatch. Yes. So that's the thing you need to add to, uh, make a, a manual. Um, this fetch action. So action, dispatch action. Well, let's not get into that, uh, word thing. Um, so, so that's, uh, that's, uh, uh, one thing. Um, let me see. Yes. There was the question on. Okay. Yeah. That's good. So we will put the URL for that one in the, in the chat.
Security, Azure Functions, and Sandbox
We provide automatic configuration for authentication with social identity providers like Google, Facebook, Twitter, and Azure Active Directory. Adding role-based authentication and authorization is easy. Azure functions have a default runtime of five minutes, extendable to 10 minutes. They can scale out automatically to handle high loads. Azure functions are cost-effective, with a free tier available. Sandboxes and student subscriptions offer additional options. Our documentation includes a tutorial on using Azure DevOps for publishing to Azure static web apps.
We promised that. If we miss anything. Yeah. So one thing we did not mention in here is, uh, kind of the, the security aspects. So in the, uh, the short link that we provided you. So in this whole list, you can actually find the link to how to add authentication and authorization, uh, to, uh, to your application. Uh, actually just one thing to mention there by default, uh, all of the authentication with, um, your social identity providers, uh, is actually automatically configured for you. Everything is wired up for you to work, uh, straight out of the box, uh, with your application. So you have authentication with Google with Facebook, with Twitter, with Azure Active Directory, uh, all of that is, uh, working automatically for you. Um, and so yeah, wiring that up is, is actually pretty easy. And so you can add role management as well. So if you want to have specific, uh, role based authentication or role based authorization within your application, again, there, you can actually easily configure the specific roles, um, within your, um, within your environment. Um, within your environment. So you can invite people and then assign specific roles to them, uh, within your static web application.
So as mentioned, our functions, uh, should now be listed here. This usually takes a couple of seconds as well. For it to, uh, to listen. So there was also a question, um, uh, Azure functions, how like does functions stay alive? Um, that's a good question. Five minutes by default, uh, you can extend that to 10 minutes if you want that. Um, you know, there's always with these kinds of things. Um, what, what is a good, uh, good time to, to let it run? What is the effect on your whole chain? You know, if it would happen that it wouldn't run longer. Uh, there's just some things to take into account, but it's five minutes or 10 max. Um, you, you can edit that that's, that's for the default. Once, um, the premium ones, uh, they can run longer like 30 minutes or like indefinitely, uh, I'm not sure if that's forever, forever, but long. Uh, and you can also there are specified that they need to be pre warmed. As well. Yep. Yep. Yes. Yeah. So, and, and these things will automatically scale out. So that's also a good thing to know that when, when you run, uh, functions, you will probably not need to worry about things like this, but, but they can scale out like, uh, automatically, uh, to quite a huge number of, um, um, of instances. Oh, you don't even know how many instances are working behind the scenes to manage your load. That's kind of the nice thing with this platform. Yeah. It's a magic, uh, like box. Yes. Yeah. And it's, it's like very super cheap to run them. Yeah. I think even when, uh, and you have a free tier as well for Azure functions, which comes with quite, quite a hefty quarter number of requests that are a monthly quota that come with these Azure functions. So if you have, uh, kind of a small application or something just for you to do kind of test drive, you can go about just using your, your free quota and never, never reach it. So I'll place the link, I think this, uh, which has an overview, uh, of a Azure functions and the limitations there are and the defaults you have there as well. Yeah. Yeah. And like, like you said, at the beginning, you can do a lot in the sandbox account, which will live for, for, uh, for hours, you can do 10 a day. So there's literally more sandboxes than one could, uh, uh, possibly consume, uh, I think. Um, but there's also the free account, so you can just create that one. You, you would need, uh, um, a credit card for that one. Um, but it, it won't get built, uh, or anything. And if you really want to, you can actually create it, uh, and then, uh, uh, remove those, uh, those bidding, uh, bidding options and, uh, and, uh, when you don't want to, uh, want to use it anymore. So that's, uh, that's a quite a quite easy to do. You can go to azure.com. Free. Well, that's not the most difficult URL to remember. And there's also a student subscription. So for students, there's, there's also an offering, uh, basically making Azure, uh, free for a lot of services as well. Um, and that's, uh, as your dot. Com slash shoot them slash free. I think, I mean, double check before I, uh, yes. Students. Shoot. So, yeah, well, yeah, not the correct URL, but there you go. Uh, let me change it to English. So one thing, uh, while Suzanne is checking that one is, uh, in our documentation of Azure static web apps, uh, you can actually find a tutorial on how to publish using Azure DevOps, rather than using GitHub repositories. Uh, for connecting to Azure static web apps. So this gives you kind of a step by step tutorial on how to configure this, um, this flow from Azure DevOps all the way into Azure static web apps. Yes. Um, so if there's any question, you can still put it in chat box. Otherwise, there's a little shameless promotion.
Closing Remarks and Stay Connected
Stay in touch with us to learn about upcoming events, grades, and useful content. Subscribe to our monthly newsletter, Microsoft Source, for hand-picked stuff just for you. Connect with us on Twitter to reach your local developer engagement person. We're here to help and provide support. Thank you for joining us!
Oh wait, let me. Oh, I don't know. Maybe I do need to need the pizza. Um, I was too fast in pressing enter, but if you want to stay in touch with us and, uh, learn like, Oh, which events are coming up, uh, learn about grades, uh, content you can, uh, you can use to, um, to do your work. Use to, um, to discover new things, uh, to, to run your applications like code examples, um, there are sometimes some fun projects like, uh, uh, making, uh, again, uh, content like that. We, we share that in our monthly newsletter and it's called Microsoft. Source. Uh, I pasted the correct link in the chat. Um, it's just my enthusiasm pressing enter too fast. Um, we curate that every month, um, hand-picked stuff just for you. Um, and you can subscribe or unsubscribe at any moment you want to. Um, but we try to make it, uh, nothing fancy, just the good stuff and share it with you. And it will be locally for your country. Um, so if you're from like, um, South America, like there's probably a decision for there, uh, within Europe we have several additions. Um, so feel free to stay in touch with us. Um, and we hope to spot you at a, one of the other events, if you want to stay in touch with us, find us on Twitter. Super active on there. Um, that's possibly also the best way to reach, uh, your local developer engagement person. Um, we are also happy to bring you. Uh, in touch with, uh, with anybody, uh, locally responsible for your country. Um, and yeah, thank you very, very much. And we will post some things into the support. Um, yes. And we hope you found it useful. We had fun and we had some troubles, Nick. Yes. We run into some problems. That's all. I'm always having one that happens, you know, yeah. We're able to solve them. Yeah. And that makes it like a yeah. Bit more exciting. Right? Sorry. Uh, um, did not run into any troubles and that we address them correctly. Um, if you did run into troubles and, um, well you weren't comfortable sharing or you have any more questions also reach out to us, we will be on this course. Um, like even maybe probably knowing this court and how I managed this court for years after this workshop, I will still be in that, in this, this court surfer. So, um, just reach out and, uh, don't be stranger. Yes. Thank you. Very, very much. Thank you very much for everything. Thank you Elvia for joining and yeah, we'll come back to your question on this court and so pursue some links there. Don't hesitate to reach out. Likewise. Thanks for joining us. Thank you. Thank you. Okay. Is this where I stopped the recording or should I? Can I stop it's cloud recording, so probably we can stop it ourselves, right? Uh, yes, I think we can stop it ourselves. Stop the recording. And otherwise it's got to last. Oh, is it's stopping? So, Yeah. Clair um well, do you want stuff? Thank you for watching the recording. If you're watching this, thank you.