>> 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]