You've built an app and you want it to scale. Do you want CI/CD, custom domains, SSL certificates, APIs, global scale of your static assets, authentication, and authorization? Let's learn how to build a static web app on Azure and go from GitHub repo to global scale in minutes.
From Code to Scale! Build a Static Web App in Minutes
AI Generated Video Summary
The Talk discusses the development of web applications and the challenges involved, such as code management, CI/CD, routing, security, and scalability. It explores the use of Azure Static Web Apps for building and deploying static web apps with features like authorization, authentication, and serverless technology. The process of creating a static web app on Azure Portal is demonstrated, along with resource creation, deployment, and custom domain setup. The Talk also covers API deployment, authentication, authorization, and role-based access control. Azure Static Web Apps is highlighted as a globally distributed solution for building web apps.
1. Introduction to Web Application Development
You've built an application that connects people who need groceries with those who can provide them. After developing your app, you need to consider code management, CI/CD, APIs, routing, security, authentication, authorization, and global scalability. There are over 30 frameworks available for building web applications, which have fundamentally changed the development process. We now build client-side applications that run entirely in the browser, requiring a new kind of application to handle this shift.
Thank you everybody for having me here at JS Nation and for all the organizers for setting this up today. I want to start with a little story for you. You've built an application, you're a developer, this is what you do and your app connects people who need to get groceries with those people who can provide them. Now millions of people could use this today in the world so let's think about what you would need after you develop your app. Of course you need your code and you probably store it in a place like GitHub and you want to push it to GitHub so make sure that you have your code available and open source but then you also want CI CD. Do you have this to make sure you're testing it and building it and then pushing out new releases? What about your API's? Are you set up to have API's and serverless functions or a backend service or how is all that coordinated? And then you might make sure that you've got your routing set up right. So you've got your app, you've got your API's, do they talk to each other well? Do you need cores set up? What about a reverse proxy? Now you get into things like security? Do you have SSL certificates in a custom domain? Of course you want your own domain for your public website. How do you establish these and how about authentication? You want to make sure you know who the people are who are logging into their app to make sure that they are authenticated and of course authorization to make sure that the roles that they provide in your application are all established already. And what about global scale? You might be in Europe or Asia or the United States or South America, you could be anywhere and your users could also be anywhere. Does your application scale around the world? Wow, you just wanted to build an application right? You just had your code and well what did you build your code with? Did you use something like Angular or maybe you used react or possibly something newer like Svelte or maybe your view developer or something else entirely? There's over 30 different frameworks that you could be using today and I'm sure that's numbers even larger. So the tools today have fundamentally changed how we build web applications. No more do we have a server runtime that we have to produce our websites and we constantly make these page refreshes. Now we're building client-side based applications or static web apps that we use and the applications are built and then they run entirely in the browser. So we've moved these application responsibilities from the server entirely into the client and we need a fundamentally new kind of application to handle this.
2. Building and Deploying Static Web Apps
Traditional web servers don't handle the build steps that apps require, they just serve the code. We need a fundamentally new kind of cloud service to handle this and this is where tools like Azure Static Web Apps can really help you out.
So thank you for coming here today, my name is John Papa and I'm going to show you how you can build and deploy a static web app in just minutes. So let's talk about what static web apps are and how Azure Static Web Apps helps you get there. In this process you're going to see a couple different things, but to sum up, you're going to build and host your web apps. You want to build them and you want to host them, that's the key part. You might also want authorization and authentication, knowing who the users are and what they can do. You also may want to have APIs.
Most applications have data somewhere, so we're going to use serverless technology, in this case using Azure Functions. You also want to have CICD, continuous integration to continually build and test your apps, and continuous deployment to deploy your applications out either to production or maybe a preview URL so you don't take your production site down when you want to see what's happening.
So that's what's happening behind the scenes. Now, it's time to actually see what's happening and try it ourselves. So let's go through a demo, but before we run into this, let's look at what we're going to do. We're going to create an application, and they're going to take that app, and we're going to connect it to an API. So we have our data with the application. And then we're going to cover authorization and authentication. So let's start where you start, though, and that's with your code on GitHub. We'll flip over to our application. So in our application here, we've got a GitHub repository which you can check out as well. Mine's called jsnationlive2020. And what I want to do is take this application, which you can see I've got Angular, React, Svelte, and Vue in here. Normally wouldn't run all four, but I'm going to choose Svelte today, because why not? This application is written in four different technologies, so you can try it yourself. And I'm going to run that app.
3. Creating a Static Web App on Azure Portal
I'm going to Azure Portal, click on Static Web Apps Preview, and add a new application. I have an Azure subscription and can create a resource group. I'll name it John Papa, SWA-JSNation, SWA for Static Web Apps. I'll choose the same name for my application and select the East US region. I'll sign in with GitHub and choose my organization and repository. Then I'll connect the master branch. Next, I'll click on build and specify the app location, APIs folder, and artifact location. After filling out the details, I'll review and create, then hit the create button to deploy the resources.
So I'm going to go over to Azure Portal and I'm going to click on Static Web Apps Preview. It's currently in preview. And here, what I can do is click on Add. And then after I click on Add, it's going to bring me to a wizard where I can fill out some steps here.
First, I have a subscription for Azure, which you can get a free trial, and I'll show you a link to that later in the demos. And I can create a resource group. Resource groups are just like a name of, it's like a folder to put things in. So I'm going to call this John Papa, SWA-JSNation, SWA for Static Web Apps. And then I'm going to give the name to my application. So we can call it the same thing for now. That's fine. And then we'll take our region. I happen to be in the East US. I'll pick it there. I'm going to sign in with GitHub so I can actually connect right to my repository. I'm going to choose my organization, and then I'm going to choose my repository, which was called JS Nation Live 2020. So I'm going to type in a little bit here so it filters it down. And then I'll choose the branch that I want to deploy. So now I'm going to connect the master.
4. Exploring Resource Creation and Deployment
Once the resources are created, we'll go take a look at the connected things. In the deployment history, we can see the app building in GitHub actions. Inside the workflow file, we have the details we filled in on the portal. The Svelte app is in the source code folder, and the public folder is where the built assets will be deployed. However, there is no functions folder.
And once the resources are created, it'll give me a blue button saying go look at those resources, which we'll do in just about a moment. And then after that, we'll go take a look at the things that it's being connected to.
So here's the go-to resource. Now in the upper right, we can see a couple things. The URL. Yellow plant. That's going to be where our web app is. We'll click on that briefly, and it's going to show us it's still building the application, which we just started. So I'll close that window.
The deployment history. This is where it's building the app inside of GitHub actions. We'll take a look at that now. So we go over to the repo, and we can see we're on the actions tab, and you can see down here, there is a yellow dot next to the action running. Yellow means it's in progress. If we click on this, we can then select the workflow file because it's still building. Let's see what it actually built for us. Inside the workflow file, there's a bunch of things here saying, hey, when you touch the master branch, even with pull requests, go ahead and rebuild this action. And in this first job, you'll notice down here on line 30, this is the stuff we filled in on the portal. So you can change this later if you made a typo. App location, Svelte app, API location, that's mere functions, and where's the code for the built assets? That's what we're going to deploy. That's in the public folder. So here we can see that. We can go back into the repo itself and look at those folders. So we can see here that the Svelte app is right there. That's where our source code is. We know public is the folder that it's going to deploy. So I click inside of here. That's the public folder. And if I go back out, we can see that we have a functions folder. Uh-oh, we actually don't have a functions folder.
5. Building and Deploying the Web App
I made a typo in the API folder, but the build still completed successfully. You'll see the steps of the build process, including NPM install and NPM run build. At the top, there's a message about not finding the API directory, but it will still build. We can click on the link to access the deployed application. We have HTTPS by default, but if we want a custom domain, we need to configure DNS.
I made a typo. That's really an API folder. That's okay. That was on purpose. We're going to take a look and see what happens when we make a typo.
So now you can see that it actually built. And here it is with the green check mark. We're going to come back in. We'll click on build and deploy on the left. And we can see all the steps are green. On the build and deploy, we can open the steps up. And it shows us everything that's happened. You'll see things like NPM install running in here. And NPM run build right here in line 88. And then at the very bottom, you'll see, you can view your site at yellow plant at this URL, which is why custom domains are so nice. We can set that up. And we can actually copy this and go to it.
But at the top, you're also going to see a message about I couldn't find the API directory right here in line 13. That's because we, I mistyped it, you didn't. And that's okay, because it's still going to build anyway. So one option is to click on the link here. I can also go back to the portal, and then click on the link right there. And here is the application that we just deployed to the cloud.
So what did we get? Well, we've got our application here. That's great. But what about security? We talked about SSL. Notice, up here, we've got HTTPS, by default, right there. Well, that's not a custom domain, though. So what if we wanted a custom domain? Because that takes a minute to set up because you have to configure DNS. Let's go look at a final solution.
6. Setting Up Custom Domain and Connecting API
You can set up a custom domain by purchasing one, setting up the C name in your DNS, and validating it in Azure. However, static sites with client-side routes may encounter issues when refreshing the page. To fix this, remove the client-side route and make necessary adjustments in the application. We have built the application, added global scaling, SSL, custom domains, and started setting up the API. Now, let's connect the API, fix the fallback route, and create a pull request for a secondary site or preview.
And you can look at this with me. It's at shopathome.dev. So this website's running. It's my domain. And at Shop At Home, we can click on this icon, and we can see that there is a certificate, and it's valid. We can go look at that certificate right here.
So what does it take to set up a custom domain? Well, if we go back into the portal, you'll notice, on the left-hand side, the custom domains tab lets us then click on add. We can then see, at the top, the first step is once you purchase a custom domain, you just set up the C name inside of your DNS, and it tells you exactly what to enter. You then type in your custom domain down here in the box, you validate it. This is where Azure will make sure you own it and have the permissions for it. And then you click the add button at the bottom. And once that's done, you'll see something like in the final solution, here's our custom domain, and there's shopathome. So that's how that works.
So we could connect in SSL and a custom domain, but one thing we have to be aware of is static sites that have client side routes, those client side routes don't map to anything on the server. What does that mean? That means up here, notice I've got slash home as my main route. There is no home.html in this particular app because I didn't use server-side rendering. If I did, I'd be fine, but because I didn't, watch what happens when I refresh the page. 404. It's not really a 404, right? Because there's a client-side route that maps to that, but I need to go back into the application and fix this, and there's a way to do that with static web apps. So let's go back, remove the home, and we can see our app.
So where did we leave off? We built your application and we added in all this stuff here. We added in our global scaling. We've got an app that's put multiple locations around the world, close to your customers. We talked about SSL and getting custom domains. We started setting up our API, which we're about to do right now, and then we also set up our GitHub pull requests. So let's go see how we can connect the API, fix our fallback route, and let's create a pull request for this so we don't take down the production site but we set up a secondary site or a preview. It's going back to our application. We need to get our code locally so we can see what's happening. So here I've got the code already cloned and I'm gonna run get pull. Why get pull? Because the workflow file was added to the repo for me.
7. Changing API Location and Setting Fallback Route
Now we can change the API location from functions to API in the workflow file. We also set up a fallback route in the routes.json file to handle 404 errors. After committing and pushing the changes, we create a pull request and kick off the build and deploy process. The final solution includes a fallback route that correctly loads the client-side app based on the Svelte router.
Now workflow files up in GitHub workflows. Now we can see it right here and the first thing I got to remember is I want to change that line 31 API location from functions to API. But before I do that, remember I don't want to change the production site. I want to do this in the preview site. So let's use a VS code commands to check out to a new branch and we'll call this my API.
Now that I'm in a new branch I can change functions to API right here and we'll save that file. And now I also want to set the fallback. So the fallback route because everything is going to the public folder, that's the deployment. I'm gonna create a new file here called routes dot json and in routes dot json I want to tell it that if you get a 404 it might not really be a 404. Go load the client-side app because the Svelte router might be able to tell you that's really this home page. So to do that I can set up a fallback route using a snippet. Here I'm saying go ahead and load the index page if we need to.
Now I'm going to commit these changes. I'm going to call it fallback and API and then I'm going to push those changes. And it's going to ask me, would you like to push to the upstream? I will say yes. Just like that. And then we can go back into our GitHub repo right here to the pull requests tab. And we should see that we have the opportunity to compare a pull request for the API and I'm going to go ahead and just create pull requests. And once you do that, what's happening is it checks. See, there's a conflict with the branch. And then in a moment, it's going to show you a message right there that it's going to kick off the workflow that we already created. And we can see that right here. We can click on the details of the build and deploy step.
So now we can see that this workflow file is rebuilding for the poll request. The main site's still up and running, but now we've got a pull request site. So instead of waiting for this, cause it takes about a minute and a half, let's go look at the final solution. In the final solution, we should have a fallback route. So here I'm on the products page. If I click refresh, notice it goes right to the products page again. I'm on home and I click refresh, it goes right to home.
8. Exploring API Deployment and Authentication
The fallback works and the API is deployed. A pull request allows switching to Vue, creating a secondary site. Authentication and authorization are important aspects to consider.
So the fallback works. And you also notice that when you click on the list, we've got our data. That's because our API has now been deployed because we told it to go to the right folder. So all of that is now connected and everything is running.
But let's go look at the production site and see I've got a pull request here. And let's say I wanted to switch from Svelte to Vue instead for a pull request, just because I'm kind of crazy like that. In this pull request, that's what I did. And it set up a new URL. Once the pull request has built and deployed, it actually gives you the link to that secondary or preview URL right here. So I can click on that. Now you can see this is my secondary site that's running and it's just a different color because it's Vue. So I can see what's happening there. So now I've got my main production site and I've got my preview URL all good to go. So we've done quite a bit with the app and the API. We set all of this up to create our application and set up our routes that we need. But what about authentication and authorization. This is usually where things can go a little bit awry. So let's go take a look at what these do for us.
9. Setting Up Authorization and User Roles
To set up authorization, go to the routes.json file and specify the authentication provider. You can block specific providers to narrow down the options. Additionally, you can set up routes with restrictions based on user roles. Authenticated users can access certain data, but editing is limited to preferred users. Commit and push the changes to complete the setup.
Now back in our app we want to make sure that we can set up authorization. So one of the ways to do that is to go back into this routes.json file. Now I always want the fallback route to be last because that should only happen if everything else fails. You know we go through the routes one at a time. Well what I want is to make sure that I have an authentication provider. And Azure Static Web Apps supports five auth providers Twitter, GitHub, Azure Active Directory, Google and Facebook. But what if I don't want to support them all? I can actually put blockers in this route to say don't support Facebook and don't support Google because maybe five ways to authenticate is just way too many. It's nothing against them we just have to narrow the field. So that will tell it look don't authenticate with those but allow Twitter, Azure Active Directory and GitHub. And now what if we also want to make sure that users who authenticate can see the data but they can't edit data? So we can also set up routes with restrictions like this so here I'm saying that you can only go to the discounts if you're a preferred user. That's a role that we're gonna create, preferred users. You can also only edit that's what the X means. I have routes under X which are editing or if you're preferred. But anybody who's authenticated can get to other data like the list of products. So now I would just commit this and push it with our PR to push it up.
10. Authentication and Role-based Access Control
Let's go look at the running application and see how this works. We can navigate the different routes and see how authentication and role-based access control are implemented. By logging in with different providers, such as Twitter or GitHub, we can test the access to different parts of the application. The role management feature allows us to assign roles to users and control their access to specific content. Inviting new users and generating invitation links is a straightforward process.
Let's go look at the running application and see how this works. So in this application right now is at shop at home. Notice I'm logged in. I'm going to log out and show you how these routes work for us. First inside of this I can go to the home page, but I can't see the list of data. I'm not authenticated so it's stopping me from seeing that. Now if I click on Facebook, remember we blocked Facebook. If I click on that, it's gonna go to page not found. That's because we told it we don't support this and this is a custom page that you can design yourself. It's just a static HTML page but if I click on Twitter, it's gonna say I'm gonna go authenticate with Twitter. It'll prompt you for permission if you haven't done so already and bring you back to the same page. Now if I click on the list, because I'm authenticated, I can see all of the products. If I click on discounts, I can't. That's because the user has to be in the preferred role. So if I log out and I log in with GitHub, I actually am authenticated in the preferred role of GitHub. Now you can see my discounts. So how does this work? Back in the application, I will show you where this gets set up. You go over to your role management, and in role management, you'll notice that John Papa on GitHub has the preferred role as well as anonymous and authenticated. If I wanted to add somebody else, I would invite them, choose the provider, type something in here, like my daughter, add something in like preferred role and click generate, and it creates a invitation link which you can expire in one hour, 24 hours, etc. So they can click on it and join the role. So that's how we set up authentication.
11. Introduction to Azure Static Web Apps
Azure Static Web Apps provides an easy-to-use solution for building web apps with a unified workflow, serverless APIs, and integrated authentication and authorization. It was just released on May 19th and offers extensive documentation and tutorials for various frameworks like Angular, React, Gatsby, Hugo, and VuePress. You can build your application and achieve global scalability.
So we just did all this stuff, right? It's like, whoa. It's built for all these different features that we have. We got everything we wanted out of the box. We'd really have to do a whole lot to get there, other than build our app, and we get all that with Azure Static Web Apps. It's all with one easy to use thing. Right now it's currently previewed, so we're looking for feedback too on what else you might like. It was just released, I think, on May 19th, so that's the opening date. You get that single unified workflow through GitHub Actions, serverless APIs, if you want them, with Azure Functions. You don't have APIs with serverless, you don't have to use them, and it's integrated with authentication and authorization for roles and access. So if you want to try this yourself, you can do everything I just showed you by going out here to the link, SWADocs, tons of docs, and there's 18 pages of them showing you how to do different things, including custom domains. You can also try a tutorial with things like Angular React's FilterView, or you can try something like Gatsby. We've got a tutorial for Gatsby, we've got docs for Hugo, for VuePress, all sorts of great stuff out there. And then you can build the application yourself and reach global scale.
Gratitude, Frameworks, and Global Distribution
So I want to thank you for coming today, and I appreciate everybody from JS Nation for supporting us, and I hope you all have a great day and give a shout out to Static Web Apps. Wow, John. As it's Sir Paul McCartney's birthday, I'm going to describe your presentation as fab, and not inconsiderably groovy either. If you wouldn't mind popping up into the virtual interrogation centre, and I will put to you some of the questions from our lovely audience, if that's okay.
Global Distribution and Authentication
Static Web Apps puts the content as close to users as possible, without any extra effort. It serves the content and allows linking to an API for stateful operations. Special user roles currently require manual invitation, but there is an open issue to explore other options. Integration with GitHub Pages is possible, but this solution offers more tailored features. Extending the authentication system beyond the listed options is an open issue on GitHub.
That actually means that there's servers around the world that are points presence in different continents and countries, and we're constantly adjusting that, too. Right now, Static Web Apps is in preview, which is kind of like an alpha or a beta. So we're testing it to see, like, are the places we've distributed around the world the places that most people are using it? So I imagine those things could change, but it's basically putting the content as close to your users as possible, and you don't have to do anything to make it happen.
Cool. Question from Beresford. Do static asset servers hold sessions or session states? Could it be mediated by a third party, but removing that computation would make getting to the 10K trio easier? What was the last part of that question, sorry? The what trio? Could this be mediated by a third party? You could use… I'm not sure I entirely understand the question, but I think if you're talking about session state in general, this is just serving the content. So if you wanted to have anything stateful about it, my ideal solution would be to link into an API that offered state. You could use serverless functions to do that, or you could actually just point to any API of your choice to manage that state between the apps. It's just a regular web app, so you could track who the user is and then use that inside of some kind of store, like a Reddit store, even if you wanted to. Mega. Beresford, if you are a ticket holder, paid ticket holder, you can go into the Zoom room afterwards and ask John Moore about that, if that didn't fully answer the question.
Drum asked, is there a way to automate user roles, for example, add role to user after payment? Does Azure offer some GraphQL and database solutions? That's a great question. So right now today, in preview, the only way to have users is they, everybody who uses Twitter, Facebook, GitHub, whatever authorization techniques you need, automatically gets anonymous, signed up for it and authenticated as a role. If you want special roles, you have to invite them from the Azure portal today. There is a GitHub issue open on this, up on our website, and I think it's github.com slash Azure slash static dash web dash apps. And I can put this on Twitter as well. And there's an open issue on this where this exact topics being talked about is having other ways for people to sign up for roles, to automatically be created in roles, etc. So please add your feedback there. Because now is the time to get the engineering team to listen to the feedback, since we're still articulating what's going to be in the final product.
Wild, and Didem, Didem, Didem, do you foresee a future where this will be integrated with GitHub pages? I can't speak for GitHub on this and where they're going with with GitHub pages. You know, like any large company, we've got a lot of products, which have slight overlap in different ways. GitHub page itself will host an app, right? But if you want, and if you just want to host an app, there's lots of options. But if you want all the things that I showed in the presentation here, with security and global distribution and SSL and custom domains, and it all just kind of works out of the box, this is a solution that's more tailored for that, as opposed to propping up a single page, for example. So could these things overlap? Absolutely. All large companies have lots of products overlap, unfortunately. Fortunately, I mean, lots of things, lots of things can overlap, but the actual product is looking at very different people, maybe. Databite asks, can you extend the authentication system to allow them for more than the five listed here? For example, configuring SAML for SSO with other organizations that might be using one logic or Okta? That's another great question. And this is also one of the open issues up on our GitHub page. So I'll refer you again to go into there to add it today.
Addressing Questions and Feedback
There have been questions on Okta, Auth0, and SAML. Please provide your feedback on the GitHub issues. The team is actively reviewing the feedback. Thank you for your input.
So I'll refer you again to go into there to add it today. No, but there's been questions on Okta. There's been questions on Auth0. There's been questions on SAML. Go ahead and add your feedback upon the GitHub issues. And I'm not kidding when I say they are literally actively looking at this feedback today. I just had a conversation about a half hour ago with the team about some of this stuff. So go up there. Add your feedback. Get your friends to add it too. Excellent. Thank you. And maybe you said you might put the link on Twitter so people can follow the link to the GitHub. Absolutely. Once we're done talking so I can actually pay attention to you.