From Code to Scale! Build a Static Web App in Minutes

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.

So your build process runs and that build process creates static assets, things like HTML, JavaScript, and CSS and then those assets have to be put up on a server somewhere which then light up your web application.

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.

All right, so enough talking about this, let's take a look at what's actually happening behind the scenes. Here we've got a GitHub repo. All of our code might be in it, and I just decided to say that my code is in an app folder, and my functions, my serverless technology, is in an API folder. You can put yours where you'd like, and then we push our code up to GitHub and maybe we make a pull request into a branch, and this fires off a GitHub action, a workflow file that then does our commands. What does that do? It runs npm run build, and then deploys the static content, or HTML, JavaScript, and CSS, up to a website, and if we have them, our APIs with Azure Functions, which are optional in this process. Then collectively, those two things become our static web apps application, and they get deployed globally around the world with multiple points of presence.

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.

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.

Next step, I'm going to click on build. This is important because while there's defaults, everybody's app structure is a little bit different. So the app location, that is where's your code located? Mine happens to be in a Svelte app folder. My APIs. Let's say I put my APIs inside of a folder called functions. And then the artifact. This is where your build location is. Where is Svelte going to put its built assets, your HTML, JavaScript, and CSS? For Svelte, it happens to be public. So I fill these things out and then I click on review and create. It's then going to give me a review screen, and then I'm going to hit create button again. And now it's deploying some of these resources.

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.

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.

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.

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.

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.

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.

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.

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.

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.

I've popped up. John's popper has popped up. Popper popped. Nice to know. Okay, so, um, one of the questions that I know everybody's going to ask you is, what frameworks does this all work with? The framework, so it will work with pretty much anything that you use today with JavaScript or even things like Jekyll. So you like Jekyll. You can use that to host these up there. Anything that creates server side web content, things like Nuxt and Next, Gatsby, Hugo. It'll work with client side stuff so you can do, you know, Angular, React, Fused, Felt, Marco, LitHTML. Actually, I've got a repo that I created called John Poppa, Hello-worlds on GitHub. And if you look at that, there's 31... I think it's 31, 31 different framework types. And I use those to, kind of, test what I can load in it. I didn't know there were 31 different framework types, but... There's some I've never heard of that are in there until recently. Yeah. I suppose I haven't counted them, the framework since last Tuesday. So doubtless another 10 have been invented since then. There's your mistake, right there. Man, framework counting should be done daily if you want to have a properly... a proper project. So thank you for... thank you for framework counting. You say globally distributed, what does that actually mean? That means you can get pizza delivered to your house anytime, anywhere around the world by... Wait, no. That's the other Papa John.

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.

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.