Hey, friends, front-end web applications often call back-
end APIs for data and services. Azure Static Web Apps provides built in
serverless API endpoints via integration with Azure Services, and Annina is here
to show me how it works, today on Azure Friday. Hey friends, I'm Scott Hanselman. Azure Friday. I'm here with Annina. She's a software
engineer on Azure Static Web apps. And you know, I'm a huge fan of Azure
Static Web apps. I got like I know ten or 11 of them, but
I think I'm just scratching the surface. I just have basic HTML
and that's kind of it. So what you basically do
is you just host like a static web, but you don't have like any API or anything,
any authorization anyway. I mean, I do a little Jekyll
and I do a little GitHub actions. I do have one that has a backend Azure function, but it's anonymous
and it's open to the public. Yeah, that's one of the backend options
we provide, right? Like managed functions
where we take care of deploying the code to the function app. Also from your code repository
and another feature that we've also provided
until now is linking a function. So if you want to like
have your function code separately, you could like host that function
and then link it. So now what though,
if you would have already like a Node.js API or something, right. And you would just like
want to host it as a web app or like a container app
if you want to be a bit more fancy. How would you do that now? I would probably start wondering,
like about what I'm allowed to do because I know that JavaScript
can call back to the origin server and I could organize cause
but sometimes I want to call, you know, websites and API
they don't have control over. So then I would probably get confused. Yeah. Yeah. I mean there are a lot of things that you need to think about
when you do that right. You almost need to become like a whole off
engineer to implement and like connect the front end
to the back end. And this is where
the new feature comes in. What we basically allow you
now is not only to bring your function app, but also bring many other backend
services. And what we do then when you link back in service to your static web app
is we secure the back end so that only the static web app
will now have access. We handle course obviously. And in addition, you can also use
the authentication from the front end. Now from the static web app
you can now use on the back inside and you can extract the user details
from the header that we actually attached to every request. So you basically can create this
like fully and authenticated apps without any off implementation,
which I think is pretty awesome. And that means a minimal back end. I mean, the back end
is a service of static. As a static web, you're hiding that
complexity from me as a back end engineer. You? Yeah. I mean, what you would do is
you would just like host your own back in service
with your own back end logic, right? You would like deploy to like a container app and then you would
have like a static web up and now you would want the static web app
though to like connect to the container without like handling authentication
of course, and also routing, which is also part right. You somehow need to route from
the static web app to the back end now. Okay. So does that mean
I want to make sure I understand because this is important
because you know this more than I really I would right now I'm writing my backend,
kind of like open in public. There's no code in my back end
that's worrying about that. So that exactly. That is being handled by the. Fully. Exactly right. Exactly. I think that will become a lot cleaner,
clearer if we just like dove into a demo. That's doing. You will be yeah. Will be a bit more visible
what exactly is happening. So now imagine we have this very,
very simple code deployed to a static web. Okay? What you
can see here is we just have like a tag that says hello
and then we append something to it, right? And what we append to
it is whatever gets returned at this root here right now, currently, when we open the site,
it just says hello because we don't have any like files
exposed that that shroud. We currently don't handle this
call really. Okay so that right now at the back
end route just to make sure I understand you're going to be going to a Nina Dot
Azure static web app slash API or this is. Yeah, exactly. That would be basically an internal call to like the default
hostname of the static web. There you go. Right. But currently there's nothing that gets returned there
and that's why it's just empty. Okay, cool. Now, let's imagine. Now, in addition,
you create it like a simple Node.js API that exposes
specifically an end point at that. Very. That's similar path. That same path. Okay. And what this API returns it for now
ignore whatever's happening in the middle. Hmm. This API simply returns this text. Stranger, please log in. Now, how do we connect those to how do we now ensure that this static wrap
up, this call is actually going to the container app and calling that
endpoint that we expose in the container very simple. Yeah. You have a question? No, I'm just absorbing. I'm trying. I'm wondering how it's going to happen now. Oh, wait for it. So the only thing we do now is we go here to static pop ups, to the static web
app that we have deployed. We go to the APIs tab and then we simply link the container up to the static web app. Okay. And what happens now is that we take care of adding
ask to the container app routing, any requests that come to the static web containing the API context
actually to the back end server. So now when we go back here
and we refresh, we can actually see the text
that gets returned from the container. You use the word you said API context. It was that the path, the actual URL slash
it was at some hidden header I'm not seeing now. It's just the path. That's the API. Magic. Exactly. You just need to eat that at that path
and you need to have a back end link to a static web up. And now any request to that static web app that starts with the API prefix
will actually get routed to the back end. Okay. This is a little nit,
but is the container app or a function or whatever listening for slash
user details at the root? Or is it listening for a
slash API slash user details. Api slash was a detail. That's actually a very,
very good question. Yeah. So like we're. Going to ask questions. The path actually need to match. Okay. So we're exposing API user details here and we're doing exactly that end
point on the static web app right now. This might be like good already
in some scenarios, but what we would actually want is we would want to like
identify the end user, right? So now what we can do is we can use the authentication
authorization feature from static pop ups to log in. This is the,
this is the out of the box authorization. And now what you can see is
we actually return my user details. So now let's look again into the API. What is actually happening on the back
end side. So what we do here is as you can see,
the API is trying to extract details from the header it summons
client principle and this is a header that we now attach to every request
from static web app to container app. And what
we can do now is we can trust this header and we can actually extract
user details from it. And then we can like in a relaxed scenario,
we would probably use that to persist this in a database with some additional details
or do whatever with it. But we can basically now use this and trust this header and so identify
whomever is locked in on the front inside. And this context will also contain a user
ID and a provider so that we can actually we don't need to use the email address
or something to identify our end user. Okay. Did I were you already logged in? I just logged in. Did you miss it? I think I missed it was so fast. So yeah. Dash my client principle and or dash name and or dash id are in that request
and available to be pulled out because you're already logged in for that
because yeah. I logged in in the front end. So what basically happens is
we have authentication authorization out of the box right, which means that we have those log in
and log out endpoints with pre-provision configured identity providers like Azure Active Directory
and GitHub and Google, etc.. And now you can just use this and points
to log in using one of those providers. And then what we do is we take the user details in the off context
and we add it to the browser. And from now on, any requests
from the static web up to the container will actually contain this header,
which we can now use on the back inside to identify the end user and all that
with like no off implementation. Now I seem to remember,
I don't know if it's in in the old days or if it's new that
there was also a hidden end point slash sort of slash me within Azure. Exactly, exactly. Very nice. And this is where we can see
all the user details. Now, that's my Yazidi. I'm currently logged in with Addy
and that's my email address. And we also have user roles, right,
that can then be used to restrict access to different. Oh, that's brilliant. That's brilliant. Yeah. And this will work for an MSI,
a microsoft account, a public Microsoft account
or an Azure Active Directory. Right. Any Microsoft principal. Or even like a Twitter account or Google,
we basically have this pre provided like preconfigured identity providers
from multiple providers. We can also log in using Google or Twitter or many more,
and it'll also bring your own identity. Exactly. Oh, okay. Cool. So you're populating X RMS client
principal with any oath provider. With the
oath providers that we have configured. Or you can also bring your own and configure it yourself. That's brilliant. I love it. All right. Now the wheels are turning about this
on my own Azure static with WebEx. You said. You said. Okay, so now
this is like a very simple scenario, but I think this is already extremely
powerful, right? Like any normal platform,
you can already use this now to build
your end to end authenticated app. Right. So what I want to demo now though is like an app where we actually combine this with and a feature,
a new feature from API management. Shall we should we do that. Let's do it. Awesome. Okay, so let's start with this. Just ignore
whatever we have here right now. All right? Okay. So imagine you have like a product
and you use GitHub issues to collect feedback
and to collect bugs or whatever. And now the problem is with that though,
that only users that actually have a GitHub account are actually able
to create those GitHub issues. Right. What we want to do now is we want to build a very simple app
that actually allows our customer to log in using Azure Active Directory
and still create those GitHub issues. Would they be doing it as themselves or would you be doing it
on behalf of them as your own identity? We would like what we would do
is we would configure an oath app that would then basically be
the identity assigned to the user, right? Because we can't use the add user
to actually post issue issues. Took it up to GitHub.
APIs won't allow that. Right. So you and I both did that. It would look like the same app. What? But there's a trick to it
that we will come to in a second. Very good that you think of that, though. Nice. Okay. So let's say we have a static web
up again. Okay. And the only thing that static web app does
is has like a login button, this button. Again, the only thing it does
is it redirects to the login end point, which you missed before. So now you got to see
what actually happens. Like we get forwarded to the off end point
and now we're actually logged in using my ID account again. I gotcha. Okay. Yeah. And so what I have here
now is like a very simple form, right? I just have like
a title and a description and a button as opposed to GitHub. Now I cannot just post an issue
to GitHub from the browsing. No. Why that is is because the user like
GitHub is not aware of it. Right. Like it doesn't know who the user is. So what we need to actually post
that issue is we'll need some like instance in between, right? We'll need some like some instance that can be configured
with an off GitHub app that will be the actual identity that
we will then use to post the GitHub issue. And that can handle the the tokens and attach the token
to the through coming request. And identity proxy. Exactly. And so what we use for
this is one of the new back in services that we allow now to be linked to a static
web is actually API management. So we have this API management
instance here. And what we did here is we configured the OAuth app like an old US app
that I previously created. It's very simple.
Just go to GitHub, you create an all right,
it gets created in your identity. So any access you have,
it will now have to. And then we configured
here with a certain scope. So now what API does is they have like a manage
token store soap and we'll take care of refreshing
and encrypting that token for you. Another bit of magic here
and what we can do now is we can actually use this off app
to sign requests that come through. So what we do to do
that is we have an API configured here, which is simply the GitHub issues API. Right? So it comes into API, Amman,
we basically forward it to GitHub issues the post and point to this repository here
as you can see. Okay. And now when we link this APM instance to our static web app and send a request again, I can show that real quick to this path here, which is. A. Simple
path of our API management instance. The request will actually go
to the API management and point and then we can do something there with it
and then we can forward it to get up. And what we do there is we use this
configured iOS app that we configured before to actually attach
an authorization header. And like that the request will
be authenticated to GitHub. Now you mentioned though that oh damn, then it's like the same app
posting over and over again. So what we can actually do
in addition is we have full control over this request
coming through to API three, right. And so what we can do in addition is
we can actually again access the EXIM as client principal header that gets sent again from the static web
up to the API management instance. And then we can do something with this. And what like I in this case decided to do with it
is I just appended a text to the buddy that says this GitHub issue
was posted by my email address and I actually even also added the buddy
to post tags which then specify in addition, this was an ADI user
that actually posted the GitHub issue. So let's just try this out right, happy
Friday. Okay. Hello from the Azure Friday and hit post to get help and again. Hmm pressure's on. Demo. Oh there. Oh, there you go. Okay, great. We'll probably end up with issues
like this. Okay, perfect. And now we can go to the issues
and refresh the page. So this is the repository. We're actually posting it to, and we're we have the new issue. And as you can see,
there are like multiple tags, add user authenticated block. Those are just like the three tags I add when I threw that policy
in API management. And in addition, I appended this text here which basically specifies
who actually created this issue. Right? That's cool. Pretty cool. It's so simple. It's just very elegant and simple. I wonder if it would ever be possible
to have it look like, you know,
if it would probably require work on the GitHub side
to post on behalf of someone. So the ADD users, which currently appears
as a little pixel icon there of you, would basically say issue
created by and it would say, oh, that's a GitHub user I know about and then say this bot
did this on a Nina's behalf. That's cool. Yeah, exactly.
This is currently not in our power. Right? The only thing we can do is basically use
this preconfigured OAuth app and then just like append as much details
as we have to the issue. That's great. That's so cool and so little code
it really APIs. Exactly. Is hiding a lot from us, but even what
it's hiding is quite simple and elegant. Yeah, exactly.
And that's the whole point, right. Not having to deal with all the different
configurations and all the different code you would have to implement
if you would handle it on your own. Right,
especially in such a complex scenario where you have like multiple identities
that you would need to handle, right? Yeah. Yeah, yeah. Gosh, I hope. You like it. You know, when I know that it's
a good episode of Azure Friday is when I start going, Yeah, which of my apps
am I going to do this with? And how am I going?
What can I built with it? Right. It's a pretty good copy and you can go
immediately and put it into practice. This has been great. So where in the docs
can we go and learn more about. Yeah, where can we learn more about this? Okay. So we have, we have different documentation because
there are different features, right. One option is of course
go to like our static web documentation where we talk about the new feature. So this is overview of API support
in Azure Static Web apps where there are all the different backends
listed. And then on top of this,
we will also be releasing a blog article with some like more details
about that specific API scenario. Also, if you're like interested
in seeing like the job policy because you actually need to do some
like configuration obviously on the inbound policy, right? You just set the header and to do this
like custom body editing, but this will all be in a blog article
and we'll also have that in examples. But yeah, here you can see all the different backend options
we provide API management, app service and also container apps
and obviously Azure functions. So all the great POS services for you
that you need fantastic. Well, thanks so much for
spending time with me today. Yeah, thank you. I've been I've been learning all about
how to integrate APIs into 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 retweeted. Watch more as of Friday.
