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 in 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 APIs? Are you set up to have APIs and serverless functions or a back-end service or how is all that coordinated? And then you got to make sure that you've got your routing set up right. So you've got your app, you've got your APIs, 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 and 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 you're a vue 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 here the process works where we have an npm run build or whatever your command might be and all of your code has to be built before it can be deployed. 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's in an app folder and my functions, my serverless technology, is in an api folder. You can put yours where you would 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 gonna do. We're gonna create an application and they're gonna take that app and we're gonna connect it to an api so we have our data with the application and then we're gonna 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 JS Nation Live 2020 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 gonna choose svelte today because why not. This application is written in four different technologies so you can try it yourself and I'm gonna run that app. So I'm gonna go over to azure portal and I'm gonna 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 gonna 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 just like a name of all it's like a folder to put things in. So I'm gonna call this John Papa SWA JS Nation. SWA for static web apps and then I'm gonna 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 gonna sign in with GitHub so I can actually connect right to my repository. I'm gonna choose my organization and then I'm gonna choose my repository which was called JS Nation live 2020. So I'm gonna 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 gonna connect the master. Next step I'm gonna 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 is 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 gonna put its built assets? Your html, javascript and css. For svelte that 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 gonna 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 gonna be our web app is. We'll click on that briefly and it's gonna 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. 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 a 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. 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 is with the green checkmark. 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 on line 88. 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. So we can set that up. 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 on 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 shop at home dot 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 this 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 shop at home. 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 dot 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. So 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 git pull. Why git pull? Because the workflow file was added to the repo for me. That workflow file is up in GitHub workflows and 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 the 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.json and in routes.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 ah 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'll 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 request 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 if 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 and click on the details of the build and deploy step. So now we can see that this workflow file is rebuilding for the pull request the main site still up and running but now we've got a pull request site. So instead of waiting for this because 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. If I'm on home and I click refresh it goes right to home. So the fallback works and you'll also notice that when we 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's 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 and 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 going to 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 that shop at home. Notice I'm logged in. I'm gonna 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 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 really had 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 preview 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 SWA docs, tons of docs, 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 Reacts, Filter, View or you can try something like gatsby. We've got a tutorial for gatsby, we've got docs for Hugo, for ViewPress, 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 to Static web apps. Wow John, as it's Sir Paul McCartney's birthday I'm gonna describe your presentation as fab and not inconsiderably groovy either. If you wouldn't mind popping up into the virtual interrogation center and I will put to you some of the questions from our lovely audience if that's okay. I've popped up. John Popper has popped up. Popper popped. Nice to know. Okay so one of the questions that I know everybody's gonna 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, vue, Stealth, Marco, LitHTML. Actually I've got a repo that I created called John Popper hello-worlds and 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 I haven't counted them at the framework since last Tuesday so doubtless another 10 have been invented. There's your mistake right there. Yeah, 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 pop wait no that's the other Papa John. That actually means that there's servers around the world that are points of 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. A question from Beresford. Do static asset servers hold sessions or session states could 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 sir? 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 key inside of some kind of store like a reddit store unit if you wanted to. Mega. Beresford if you are a ticket holder, a 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. I'm not sure I put it to him particularly accurately. 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 an authenticator 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 didum didum didum 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 show 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 that overlap unfortunately. Well fortunately I mean lots of things lots of things can overlap but the actual product of looking at very different people maybe. data bite 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 no but there's been questions on you know Okta there's some questions on Auth0 there's some questions on SAML go ahead and add your feedback up on 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 an hour ago with the team about some of this stuff so go up there add your feedback get your friends to add it to. Excellent thank you and maybe 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. The last question is possibly the most important if you were hosting a dinner party and you invited me because why wouldn't you Napoleon and Cleopatra what would you cook? Well first I'm very Italian I love Italian food so it would have to be anything with a lot of sauce cheese noodles and meat all put together so a lasagna would be an amazing thing to have of course there's an antipasta before the meal but the food is not the important part here the important part is the conversation can you imagine having a chance to talk Cleopatra and Napoleon and me and you but that'd be pretty cool. Yeah at first I thought maybe Cleopatra wouldn't like Italian food but then I suppose as she had a torrid love affair with both Marc Anthony and Julius Caesar who were Italians they would at some point have cooked a lasagna you imagine. You would think you would hope. If I if I were trying to seduce an Egyptian Empress I would cook a lasagna. Stick around please John and get yourself into the speakers room where you can take questions from paid punters in the zoom room. Thank you very much for your talk it was really cool.