>> Hey friends, Azure
Static Web Apps is a service that automatically builds and deploys
full-stack web apps to Azure from a code repository. Apps are built and deploys based
on code changes using GitHub or Azure DevOps Pipelines
and Anthony Chu is here to show me how it works
today on Azure Friday. [MUSIC]. >> Hey friends, I'm Scott
Hanselman and it's Azure Friday, I'm here with Anthony Chu who's
going to talk to me all about Azure Static Web Apps.
How are you, sir? >> I'm great. How are you, Scott? >> I'm doing great. I'm
actually really excited about Azure Static Web Apps because I've recently converted a
bunch of my sites. I had some Razor sites, I had some Jekyll
static generated sites, I had a bunch of
Brochureware sites and I had been running them all
in a small Azure Web App. I've got rid of that,
I'm saving money, moved it all the Azure
Static Web Apps, I think about nine of my sites
now our Azure Static Web Apps. >> That's awesome. >> Yeah, I'm learning a lot. >> Let's talk about
Static Web Apps then. Let's start with talking about
why Static Web Apps matter. I think more and more
apps now are built with frontend frameworks like
React or Angular or Blazor and a lot of the
work that used to happen on the server-side have now
shifted to the browser. These apps need very different
hosting capabilities compared to your ASP.Net or
Express.js applications. We need to be able to serve static files really
quickly and ideally, we distribute the static
contents all over the world so that it's
super close to your users, so when they try to
access your site or your application, it
loads really quickly. Azure Static Web Apps is a service that's built
for these types of apps. At its core, Azure Static Web Apps makes it really easy
to take your code from your local machine to a source control repository
like GitHub or Azure DevOps. Every time you push a
commit to your repo, we will automatically build and
deploy your application to Azure. As I was saying before,
for your static contents, we'll actually distribute that
globally for you automatically. If you need any backend logic, you can optionally create a serverless API using Azure Functions and you
can source control that function app in the same repository as the rest of your
web app so they can build and deploy your entire
application as one unit. >> It really shows the
shift in philosophy, it's an interesting and
different philosophy. Like I said, I had some sites that were mostly static with a couple of API calls to a backend and
because those applications got, they went from being very static
to being a little bit active. Suddenly I had to take them out of hosting in Azure Storage and then I had to spin up a VM or I had
to go and think about hosting, but with this, you
got best practices, CDN, scalable backend, all codified into one service. >> Absolutely. Should We do a demo? >> Let's do it. I love demos. >> I have a pretty standard
React application. It happens to show the weather, this is literally all
the code that I wrote. I just used a widget that
somebody else published and then it's going to go and
call an API that doesn't quite exist yet, to
grab the weather. I think to start off with, let's look at how you would
typically run this app locally. It's React app, so you would just
start it by npm start. It's going to start up the React app server just to see what it does. Then this gets opened over here. You can see that it has
failed to load the weather. That's a little bit sad, we can
add this API fairly easily. I'll go ahead and stop this, and then using the Azure Static
Web Apps extension in VS Code, I can actually go ahead and create an HTTP function in my application. It's like JavaScript, I called it weather, then it creates a function
here that we can modify. I've already done this,
I'll just paste it in. All we're doing is that we're
calling out to Azure Maps, which I just found out the other day has a weather API that I can call. I'm just basically calling that API and then returning the contents. I'm going to actually do this
from the browser as well, but I really want to keep my
subscription key to myself. Eventually I might even
want to allow logged in users or visitors
to get the weather, but not anonymous users. That's why I have it in my function. Now I have both a
function app that's on my machine as well as my React app, typically, to test this out, I would have this
term, our React app, and then start my
function app and then figure out how they can
talk to each other locally because they're on two
different endpoints lawfully and you have to worry
about cores and all that stuff. In Static Web Apps, we actually ship a CLI to make this
really easy for you. To install the CLI,
just grab it from NPM and this npm install this thing, and then we now have a CLI. >> A CLI command-line interface. Now like you type NPM this
and NPM that I can do something with Azure Static
Web Apps at the command line? >> Yeah, so now I can
type the word swa. >> Static Web Apps? >> Yeah, then I have basically a command line that I can start up. I actually forgot one thing,
is that my app requires a library to actually
talk to the API. I'm just going to install that. So npm install axios. We support, installing
packages and stuff as well. >> Sure and axios is what you're
using to do that HTTP GET. It looks like you're
just calling that Azure Maps API and then just brokering the call back
to your Static Web App. >> Exactly. >> Okay. >> To start this whole thing
up all at once, using the CLI, you type a command called swa start, I had to call it the local
endpoints to proxy 2, for the React Web Servers,
that's localhost 3000. >> It's a simulator, a
Static Web Apps simulator? >> It's a simulator and later on, we're actually going
to look at how we can simulate authentication with it, which is really difficult
to do locally otherwise. Then we can run with a run command. So npm start with the
run command as we saw earlier and then I also want to
tell it where the API lives, it lives in the API folder. Because this command alone should start up everything that I need, both the React Dev Server as well as the Azure Functions core tools that runs my
function app locally. Then it gives me a single
endpoint that I can call locally at port 4280. Now if I switch back over to my
browser and I go to port 4280, you can see my application. Because it was able to call the API, it now returns the weather. >> I think I understand here, so 4280 is simulating Azure, returning the static
part of the stuff, and then the actual NPM, the JavaScript application
is running on 3000. This is our index.html, this is our endpoint for our application and when
you put it up in the Cloud, it'll be whatever domain you want. >> Yeah. Then anything
that is at /API/something, /API/weather is going to be
routed to my function app. This is the result of my function. They're both under the same domain, just like it happens in the Cloud? >> Just like it happens in
the Cloud. Isn't that cool? Dealing with multiple
services locally like that, all the different localhost and
the ports can be very confusing. That's a very nice way to make
that simpler for everyone. >> Absolutely. Let's take a look at how we can actually
deploy this to the Cloud. I'll stop my app and then I'm
using the same VS Code extension. The first thing I need to do
is actually make my commit, I can add API. Commit it to Git. Then I will use the Azure Static Web Apps extension and say create Static Web App
and choose my subscription. It's going to ask me
if this is really the branch I want to
use, let's say sure. Oh, and it wants to reload
the window, fantastic. >> I think your extension just updated itself as we
we're doing that stuff >> Yeah. Let's try this again. >> This time, hopefully, here we go. It's going to ask me for the
framework that I'm using. What this is, is it allows
us to pick some presets for some settings so that you don't
have to figure it out yourself. >> That's a pretty
comprehensive list. >> Yeah, and this is not all
the things that we support. We actually support pretty much
anything that can compile, especially in JavaScript, as
well as something like Blazor. You mentioned Jekyll
and Hugo before. We support all those.
Basically we have to give it a couple of piece of information. One is, where does my app live? It's just living at my route
so I'll just say that. Then also where is
the output of my app? When I run npm, run build, which is what the service is
going to do on my behalf. It needs to know where
the app is built too. Depending on the framework it
lives in a different location. For React is in the build folder. If I press "Enter", this
will actually go and create my Static Web App for me. But I've already done this so
I'll show you what it looks like. This is an app that I've already deployed. It's the exact same app. When I actually go ahead and
finish the deployment process, what Azure does behind
the scenes is that it creates a GitHub workflow for
me to deploy my application. I'm actually going to
create this file based on what I enter there in those boxes. Every time there's a
commit to my branch or any pull requests that
are created against my repo, this will fire and then
your app will build, and then it gets deployed. If I go back to my code, I can actually take a look at
the GitHub action that gets run. This is the GitHub action that ran and it deployed it to the Cloud. If I scroll all the way
down to the bottom, it has the URL that I can click on to actually see the site
that was deployed to. The app is using the browser's
location API to figure out where I am to get the
weather for me, and there it is. I also have a custom domain created as well for it so my app it's under weather.anthonychu.dev. If I go there, I have a site that is using this custom domain and Azure
Static Web App actually provides a free SSL or TLS
certificate when I add a custom domain so
I don't have to do any extra work to
manage my certificates. >> That's a thing
that I know that you know I'm super excited about because I've got babysmash.com and all these little projects
that I do on the side and we're moving to an HTTPS all
the time environment. Chrome and soon Edge
are going to basically default to HTTPS for everyone and certificate management
for small hobby sites are no fun and I love it that Azure Static Web Apps are managing that certificate for you just
makes our lives so much easier. I was honestly spending time all the time with let's
encrypt certificates and background jobs and anything I could do to just make
sure that my sites were secure and that's gone. Azure Static Web Apps
handles it all for me. >> Yeah, absolutely. That's one
of my favorite features as well. >> Awesome. >> All right. Let's
take a look at a couple of more advanced things. Like I was saying before, maybe it would be nice to only allow an authenticated
user to access my API. Azure Static Web Apps has
authentication built-in. Out of the box we support
things like Twitter or GitHub or Azure Active Directory, or you can actually plug in any OpenID Connect
compliance provider. We basically handle
the login for you, and then what you can do after
that is you can actually restrict access to routes
and things like that, whether the user is
authenticated or not, or even using roles. To do that, I'm actually
going to switch over to a branch that I've
already done this on. To do that, we start
to add a file called staticwebapp.config.json. This file, you can
actually use it to configure a bunch of
other stuff as well. Anything related to Auths,
like I was saying earlier, if you want to set up
different Auth providers, this is where you do it. If you wanted to
return global headers, if you only had supporting
custom headers, mime types, or do any networking
stuff, you can do it on here. I just want to point out a couple
of things that I have in here. One is this thing called
the navigation fallback. A lot of these frameworks
do client-side routing, and when the routing
happens client-side, and somebody takes this to
the route that they copy from the location bar and then they give it to someone else
so they reload the page, the server the thing that's
serving your static assets. Actually don't know anything
about your hindsight routes. Pretty much all the frameworks like React or Angular
or Blazor or View, requires what we call a
navigation prop fallbacks. No matter where you navigate to, we want to serve the index.html. This is the role that you
would put in here for that. We can also apply rules for
free for specific routes. Here I'm saying that anything
that's hitting the API endpoints is only going to allow
authenticated users to access. To run this, I've actually
configured this version of the app to actually
launch from VS code. What I can do here now is, I go over here and
press basically a five, it's going to run that
same command that we saw earlier that I ran. But I've configured VS
code to start this. Now both the React Dev
server is going to start, as well as Azure
Functions, core tools, and the Static Web Apps CLI. Pretty soon, hopefully,
the site will load here. Give it another second or two. >> You have to hit
"Refresh" couple of times? >> Yes, we do. Basically, what
happened is I have a little bit of extra code in the app
that says if I hit the API endpoints and
it says unauthorized, please bounce the user
to the Static Web Apps, basically a built-in
login end points. In this case, I bounced them
to the GitHub endpoint, the font maybe a little bit small so you might not
be able to see it. In the Cloud when this runs, it'll actually make you
login using GitHub. But locally, you don't really
want to configure this. What we actually decide
to make it possible to do is you can just pretend to be anybody you want because
you're just running locally. If I wanted to be you or if
I want to be somebody else, I could basically punch in the
information here and click login, and now I'm logged in to the app
and I have access to my API. >> Nice, so it's great
for testing locally. >> Yeah. I can also set
breakpoints as well so by actually just quickly going to go in here and drop a breakpoint
here in my Function app. I can go into even my little weather app and drop a breakpoint somewhere in here. Hopefully this will get executed, so that I should go back to my page. I hit "Reload", it's actually hitting a breakpoint
that's in my client side, JavaScript right now
in my React app. If I press a little play button, it's now going to hit the
breakpoint as in my Azure function so basically, you can
now attach a debugger to both your front-end
and your back-end and debug them together locally. >> That's pretty slick.
Being able to simulate the Cloud locally really makes things easier when
you go to production. >> Yeah. Then if I wanted to
take these changes to the Cloud, I can go ahead and
create a pull request. I've already done that here, so we don't have to wait
for that to happen. But you can see that I've pushed this branch up and I
created a pull request. What we do for pull requests is that we will actually stand up
a staging environment for you that is temporary
for the lifetime of your pull requests when you close your pull request will
delete this environment. You can see that I can
actually go ahead and navigate to my staging environment, and I believe the
staging environment has the GitHub Oauth
enable, or it doesn't. I think I'm logged
into GitHub already. >> Right. You're already logged in. >> You can quite see that. You can trust me that
it actually worked, that it would redirect me to
GitHub and [inaudible] login. >> That's another great thing
that Azure Static Web Apps offers for CICD environment is if you and another person
are working on something and they can see in the PR, the staging site, it really
accelerates that developer loop. >> Yeah, absolutely. >> Very cool. I'm loving it. I love Azure Static Web Apps. I mean, people are sleeping on
this and they need to like, one of the great things
about Azure Friday, you can show something to
someone and they should, hopefully if we're doing our jobs, either pause or when it's done go, I need to go and make
this happen right now. I need this to just stop everything, and when I heard about this stuff, I started just changing my
sites over immediately. I had virtually no downtime to move things over from Azure Web
Apps to Azure Static Web Apps. Now my personal, The
Hanselman Incorporated, is a combination of functions in Static Web Apps and
then Azure App services from my more complicated sites. >> Nice. A great place to learn about how to build your Static
Web Apps is at Microsoft Learn. We have quite a few modules, so many that were actually built
a learning path out of it. Anything from learning
to just get started, as well as learning to add an API, or how do you authenticate users, or even learn how to deploy an entire Blazor Web Assembly App
to your Azure Static Web Apps. That's all here for you to try out. >> Fantastic, this is great. Gosh, I know, I gosh, sometimes, but I gosh about Azure
Static Web Apps because it's just that perfectly
sized screwdriver in my tool box that allowed
me to go and make my sites just that much better, and I would really encourage
people to check it out. Thanks so much for hanging
out with me today. >> Yeah, thanks for having me Scott. >> I am learning all about
how to get started with Azure Static Web Apps
today on Azure Friday. >> Hey, thanks for watching
this episode of Azure Friday. Now I need you to like
it, comment on it, tell your friends, retweet it, watch more Azure Friday. [MUSIC]
