 How do single-page applications differ from static sites? With Azure Static WebOps, we can deploy single-page applications and multiple-page applications, also known as static sites. Static sites are faster as they're already rendered, whereas single-page applications need to render in the browser. That means that the initial page load can be a little bit slow which can affect performance. With static sites, they're much faster, which improves performance and also search engine optimization, because it's already rendered. But of course, with static sites, you need to regenerate the content when it changes. Regenerating with Nuxt.js actually doesn't take that long because we separate the content from the build. So if you only change your content, we can regenerate just the content without having to rebuild the whole site, which basically means regenerating literally takes seconds. Hey, everybody, it's your buddy, Jay Gordon. I am back here on Azure FunBytes. Once again, we get together, and what do we do? We talk about the people, the products, and the services that make up an incredible Azure experience. I am so thankful that you join me here, almost every week, to talk about the various things that we can do with Azure. And we've learned a lot. This is episode number 69. There's been a lot of these. And we've covered a lot of different topics, and sometimes we like to revisit topics that we've talked about in the past. And one of those specific topics that we'll be covering today will be Azure Static Web Apps, which is one of the really great products about helping you build faster, build better, and just not think so much about the infrastructure or configuring your CI CD pipelines. A lot of that stuff is done for you. And we're gonna learn a little bit more about that. And to help me out today, I've got two really great guests. Two, that's right, you get a two for. First up, I'm gonna introduce Simona. Hi, Simona, how are you today? I think you're muted as part of the course. All are, right? Yes, part of the course. Welcome, Simona. Hi, Jay, thank you so much for having me. And hi, everyone. Thank you so much for joining us today. I'm really excited about today's episode. And I think the name says it all. I'll focus on the part. And also the vibe. Cool. And then also to welcome back to the show, I'm very thankful to have Anthony Chu, both of them work on the product. They've really put a lot of time into thinking about how to best get it into your hands, how to best make Azure Static web apps work for you. And one of the really cool things, like I said, Anthony was a guest before and go back in time a little. Both of us, cheese in real hard with smiles. Hi, Anthony. Wow, we looked so much younger back then. How are you doing? I'm doing great. Great. So where are you both broadcasting today from? So I am broadcasting from the wonderful Zurich, Switzerland. And I'm originally Romanian. And before living in Switzerland, I was also based out of London. So hi, everyone, that's streaming from London. I do miss London. I haven't been there for the past two years. But yeah, streaming from Zurich. And Anthony, you're living in the Redmond region, right? I'm actually in Vancouver, Canada. Oh, that's right. I'm sorry. I'm sorry, cloudy, dark Vancouver, Canada. That was nice to hear. Wonderful. Zurich. Yeah. Can you take your cold back? I don't want your Canadian cold weather much more here in Brooklyn. It's definitely been blowing down from your side as the way I'm thinking about it. Yeah, to send it back, return to center. Yes. So things have really progressed with static web apps. The product has really evolved in the last few months. Since it was originally announced, was that at Igniter build, I remember it was around that, one of those events. It was announced at build last year now, I guess, like when 2022, right? Yeah. So we've been GA since May last year. Very cool. So before we really jump into today's subject, which is Azure Static web apps, I wanna ask you both some questions, but before that happens, there's some housekeeping I wanna get done. First of all, if you are watching Learn TV, you can go ahead and head over to the right rail and you'll see there's lots of docs that you can follow for today's show that talks a lot about what we're looking at, how you can start using it, how you get free education around that. So head over to the Learn TV website. The other thing that I really think you're gonna get a lot out of is the Microsoft Learn module around Azure Static web apps. So why don't you head over to that URL, but not right now, wait until after the show. You can look at all the show notes and everything else. So you can start getting free education about none other than Azure Static web apps or any sort of great Microsoft product. There's so many different modules. We've all spent some time with them in the cloud advocacy team and DevRel in general. There's a lot of great content that gets produced. So now that we've got a little bit of that housekeeping on the way, there's something I always like to ask my guests because I just wanna learn a little bit more about you before I learn about product. And I always ask this question and Simone I'll ask you it first. How'd you get here? I was hoping that Anthony would go first because then I would get to follow his lead since he's already been on this show before but I can share a bit. So how did I get here? I'm a product manager on Azure Static web apps and actually before joining the Dev Dev group so the developer division at Microsoft. This is where all of the magic happens. This is where VS Code and TypeScript has been created. So it's an incredible honor to be part of this group and to be serving all of you out there. Before I joined this group, I was actually part of DevRel which is another team that I have been incredibly grateful and just humbled to be part of working with folks like yourself Jay and other wonderful folks like Anthony as well. So we're here at DevRel alumni and as part of that work, our goal was to serve developer and developers and developer communities engaging with all of you out there with content, with product and with open source. Very, very cool. And so thank you so much for a little bit of that. I love hearing about how our guests got through and what they're doing. And Anthony, since you get to go second, I'd love to hear a little bit about you, your background as well. How did you get here? Exactly, exactly? Well, so thankfully Simone covered a lot of it. I think myself and Simone started like roughly around the same time at Microsoft in developer relations. And yeah, and I kind of follow this similar path to product management like Simone and started off with Azure Functions and then now working on static web apps and also container apps as well in Azure. Yeah, there are so many new cool ways of being able to host the different applications, websites, things like that, that come along with building them. You've got to have a place to put them. What good is making these applications if you don't have a trusted place to actually put them so that your reputation as your business or whatever it is you're trying to accomplish is maintained. And that's one of the great things that we'll be talking about today is how far and how what a great spread you can add into the front of your Azure Static web app to ensure that you have reliability, availability and speed no matter where your viewers or I shouldn't say your users are coming from. So that all being said, we've got the big ideas out there. And I think it's worth it to kind of go back a little bit through the Azure Static web app and talk a little bit about what it is and why it is. So would one of you want to just give us a brief rundown on what Static web apps it is for those who may have missed the last show? So I'll quickly start and then hand it over to Anthony. And Azure Static web apps is one of the most wonderful and one of my favorite products out there on Azure. And Anthony, do you want to share more about what the company is doing? Sure. Yeah, like I think we probably want to, yeah, like go a little bit over what Static web apps is. So it's a nice place to kind of develop or to deploy your, as the name implies, your Static web apps too. So these are apps that are built in React, Angular or Vue or something like Blazor Web Assembly or something like a Static site generator like Hugo or Jekyll or Gatsby. So you could deploy all of those things really easily from GitHub or Azure DevOps to Azure Static web apps. And we host that for you with distributors around the world. So they're super close to your end users. So there's minimal latency and it gets served up really fast. And if you need some backend capabilities, you can always add an optional serverless API backend using Azure Functions. And you just have an Azure Function app in the same repository as your front-end app. And we'll take care of deploying the front-end bits to the front-end parts of the service and we'll also deploy your function app as well. So at runtime, these two things work together as one holistic application. So your front-end code can easily call APIs and have those API software databases and things like that. Yeah, and if you don't mind keeping that screen, I also want to mention, so Anthony talked about starting us starting from GitHub and really hosting our code there and collaborating with folks around building applications. One of the cool things about Azure Static Web Apps is the fact that we also create preview environments whenever you submit pull requests against your main branch. In return, we give you back a URL where you can see your preview environment with the changes that you've just made in that PR. And another feature of, another favorite feature of mine that really makes everyone's lives easier is actually the authentication integration. So currently Azure Static Web Apps has support for authentication, managed authentication providers like GitHub, Twitter and Azure Active Directory. And it is as simple as really building, for example, a Next.js application and adding into your application, into your front-end application, a link that points to system endpoints that's hosted in Azure Static Web Apps that allows your end users to log in with any of these providers. And as you'll see in today's discussion, we also have support for a set of custom authentication providers that Anthony will talk about in a lot more depth. Very, very cool. And I really like looking at the actual workflow that comes from this because what you're really doing here and it's something that we always wanna remember is DevOps is the union, our friend Donovan says, DevOps is the union of people, process and products to enable continuous delivery of value to our end users. And one of the things that I believe Static Web Apps really does for our users is provide that value because you're implementing DevOps methodologies and using tooling that is familiar to DevOps professionals and people who are developers to be able to build infrastructure, really useful infrastructure for their apps without having to really concern themselves with everything that's going on in the background. And so I wanted to talk for a second just through this little set of graphics that I have here. And the big basis I believe of this and you can correct me if I'm wrong is that we're putting our code into repository. And then after we've put our code into that repository, we're creating a push, a PR to GitHub or Azure DevOps. In this case, we're talking about GitHub. And that kicks off either a pipeline or a GitHub action which starts your build process, gets you your testing and everything. And then eventually the package that's created from that gets sent over and put into Azure Static Web Apps. So our static content like our JavaScript, HTML, CSS and the embedded tools that you might have in there like authentication and your Azure functions are all part. So did I get that right? I just wanna make sure. 100%. Awesome. So there's a lot to be seeing around Azure Static Web Apps and we talked a little bit about some of the key features and I had them up. I'm gonna bring that up for one more second. So that integrated API support using functions and we'll talk a little bit about those functions, the integration with GitHub and Azure DevOps, all the way down to these other things like the backend routing rules and the staging versions. And I think those staging versions are really, really useful. It's nice to see that there's an effort to think about the developer and what the developer is actually building. And so I really dig that. So I've got some questions that are coming in from our viewers. I wanna say hi to everybody. We've got a lot of people who are watching. We've got ToeFrog here. Mark wants to say I love static web apps, create a bunch of sites with 365 off. They love how it works. We also had this one Azure Static Web Apps helped a lot when they needed to leverage a web solution from a storage account, lots of great things and our friend, John is here as well. Just wanted to say hi. Thank you very much for watching everybody. And so we've gone through those and I have at least one question from the audience that I'll share at some point, but I've got a couple of questions to get started with. And one of them has to do with the idea that you've in those new features have improved the reliability aspect of websites for your users by focusing on what you call enterprise grade edge. And so can you talk a little bit about what that is and the tools that kind of go into enabling a site to be enterprise grade edge? Yeah, so I can briefly cover this. So basically recently we announced the preview of enterprise grade edge in Azure Static Web Apps which is powered by Azure Front Door. And one of the key things that we want to highlight here is that basically by enabling enterprise grade edge in Azure Static Web Apps, you are extending or enhancing the global or benefiting from an enhanced global network that benefit actually your end users. And currently what we're doing is we're distributing and caching your static assets across 118 plus locations across the world across 100 metro regions. And we do that without any code or configuration required on your site. And I want to bring up my screen, Jay, so that I can show everyone what is needed in order to enable enterprise grade edge. So assuming you already have your existing Static Web Apps or your existing web application deployed to Static Web Apps, for example, I have this wonderful application that's built in collaboration with Anthony and it's actually a starter application built by the team at Strapi, which is a content management system. And it's built on top of Next.js and it is basically helping us sell stickers. And any chance, I'm sorry to interrupt, Simona, would you mind bumping up the zoom just a little bit, just so our viewers, I don't want them to miss any of this. Thank you. Of course. So we have this web application that's deployed to Static Web Apps. And one of the first things that you can see here is that I have a custom domain. So this application is hosted at azurestaticwebapps.art And it is hosted and configured in Azure Static Web Apps to include this custom domain. You can do that easily, configure that for your web application. So that's one of the prerequisites for enabling enterprise grade edge. We need you to set up your custom domain for your application before you can enable it. And the other prerequisite is that you are hosting your application in a standard plan. So we build this feature with production applications in mind so that we can ensure that SLA, that service level agreement that requires folks to build things in production. So next thing that we can do is go into our enterprise grade edge tab here or page here. And you'll see here that the only thing that we need to do is check this checkbox. And in the background, what Azure Static Web Apps is doing is it is managing and distributing and caching your static assets across the 118 locations around the world. And you'll see that in the resources that Jay will probably share in the show notes here. I also wrote a blog post that you can read on the Azure blog website. And there's a documentation that walks you through how you go about checking this box. So I have a question for you, specifically for those who may not know what front door is, it's a global scalable entry point that uses Microsoft's global edge network to create a fast secure and widely available web applications. We talked about how this is enabled through turnkey methodology using Azure Static Web Apps using enterprise edge. But the question is like, love it. What if I wanted to set up my own Azure front door with that work? Yeah, so we have had this question before from customers and we recognize the fact that some customers might prefer to use this simple setup for their applications and really use a managed version of Azure front door and use this single checkbox to enable everything behind this checkbox basically. And the other option is that you set up and you configure your own and you manage your own Azure front door. It might be that customers need to connect multiple types of applications or put Azure front door in front of multiple types of applications or it might be that some customers might want to configure a web application firewall in front of their web app. And in order to do that, they need to spin up their own instance of Azure front door. And today you can do that with Azure Static Web Apps as well very easily. And Anthony actually wrote the documentation in collaboration with Craig on that. And there's two things that are happening that you still need to configure as you're spinning up your Azure front door. And that's the same thing that we're doing and that's setting up your forwarding gateway and basically ideally you want to restrict traffic to your Static Web Apps to be coming from only Azure front door and furthermore your own instance of Azure front door. Very, very cool. Thank you so much for answering that. I got a really great comment here, the custom domain configurations. One of our viewers' favorite features. It's simplifying everything and they're looking forward to implementing the private endpoint and functions in their next project. I know we're gonna talk a little bit about functions with Anthony in just a few minutes. I do have a question about you mentioned there's the availability to have multiple versions of your site within an individual Static Web Apps with different environments. Someone wants to know, will there be a way to publish multiple versions of the same app? Would be awesome for QA. I'm not entirely sure what that means but maybe you understand. So I can, and I'll see if I can understand this, maybe if I understand this correctly. But my guess is that the question is around this feature around environments. So assuming that you have a web application that you are building and you're building new features like adding a new page or adding a contact API and you don't want to push that to production yet, you want that to be available in an environment that's available for your QA team. And as you see here, we have the production environment which is available at the custom domain URL as well as this default host name but we also have a set of URLs that are, well here I think my environment. Okay, so we have a set of four other applications that are running in parallel with our production environment which are available for testing. And you can see that my staging environment or this version of my application includes the region where my staging environment is hosted and the number of the pull requests that I've created. And I guess that answers, hopefully answers the question earlier. Yeah, I think that question came from Jerome and I think Jerome is like a, if I remember, I think he's a long time user of static web apps. So they might be asking about like, what if I wanted to have an environment that I want to stick around forever so that it's not one that's created at the start of a pull request and then torn down when I close the pull request. So that is a feature that we are actually kind of considering and working on. So if that is what you're kind of asking for, hopefully we'll have something for you in the future. So I'm curious, how many environments do you get in a standard SWA account? Like, can you have a number of different environments that or is there a certain limit around how many you can have between production and staging? Currently we give you 10 for the standard plan and I think three for the free one. Sure. Can you purchase like a greater number if necessary? So currently what we're looking for today, maybe if folks can share in the chat as well, if they have any feedback around this currently, our limit is at 10 as Anthony mentioned, but it would be great to hear the types of scenarios and use cases that folks on the line are also experiencing in terms of these types of environments and the numbers that would be useful for them. Gotcha. And so Andrew has a question and then I'm gonna start talking a little bit more with Anthony about the next little bits that we've got planned in our agenda. Andrew is from the IT Pro side of things and wants to know what are the use cases for SWA? It's obvious we saw a little bit around blogging and e-commerce. So are there any other major ways that you can use this for different types of products that people are building? So we're really seeing users build a variety of types of applications deployed on top of Azure Static Web App. So think about your documentation websites. Think about your landing pages. Think about maybe a campaign. I'll give the example of the recent Xbox anniversary. If any of you played the game that was created in collaboration with The Rock, then that was hosted on Azure Static Web Apps. And I think those are just a couple types of examples, but generally when you're building client applications and you need to deploy them globally or you need to really distribute your assets closer to your users, Azure Static Web Apps is a good example. And I know Anthony, we talked a lot about also internal types of applications. Yeah, so yeah, I think another thing that we see a lot in like, you know, internal IT kind of applications is that you kind of want to deploy like you kind of mentioned, you know, documentation sites and stuff like that as kind of like, you know, developers that work in these organizations kind of like start building more and more in these apps using these newer frameworks. They're looking forward to actually buying to this new workflow that, you know, like where you commit to a Git repository somewhere and then you kind of have that code available for preview and then eventually into production. So Static Web Apps actually, you know, gives them a better way actually achieving this workflow for their internal apps. And then for that, for internal apps specifically, we added a bunch of security related features recently. So we added private endpoints. So you can actually now have Static Web Apps kind of like in your VNet. So that it's only available to folks in your company. You can also make it available externally as well and actually lock it down with Active Directory. Okay. Yeah, so we've seen a lot of customers actually internally wanting to use this and it's mostly because it better fits the technologies that they're using as well as the workflow. Whereas in the past, you would deploy this to maybe app service or, you know, host it in a VM somewhere. But when you really just have a bunch of Static files, maybe a couple of optional, you know, functions APIs and that fits a lot better than Static Web Apps. And it gives you more than just the thing you would get from say a storage account that was done when hosting enabled. Because you're able to do the custom domains, you're at authentication, authorization, the support for SSL obviously out of the box, really, really useful. And one person, you know, we'll talk a little bit more about it once to know if, is this compatible with a Let's Encrypt certificate or do you need to use a certificate provided through Azure? Yeah, we actually provide you a free certificate out of the box. Yeah, so as soon as you set up your custom domain, we'll provision you a free certificate. And so you don't actually have to use anything like Let's Encrypt. We take care of giving you a cert. So you're always accessing your site using HTTPS. Got you, got you. Jerome actually is putting some chat, asking those questions. We'll see if we can get to some of them as we get some free time. But I have a question about this authentication service that we have. So you mentioned being able to use Active Directory and I'm curious what off providers are supported out of the box for static web apps? Yeah, so we support GitHub Active Directory and Twitter right now, but you can actually configure your own custom authentication provider. But I should talk a little bit about the built-in ones first. So the advantages of actually having a built-in support for GitHub Active Directory and Twitter is that you don't have to do anything. You don't have to go to GitHub and register an application and then figure out what the client ID is and the client's secret and all the stuff that have very funny names and interesting values and you have to figure over to plug them into your application just so that you can get some authentication. We handle all that for you. So all you have to do is just basically navigate your user's browser to a predefined URL that we give you and then we'll actually take care of logging that customer or that user in to GitHub for example and then you have access to some simple information like their GitHub handle and stuff like that so that you can actually make decisions about it both in your front end as well as you can actually use that information in your back ends to decide what they're able to see and not see and return data based on their user profile and things like that. Gotcha, did you want to show me some of that authentication enablement that's built into the service? Yeah, actually I could show it to you. Yeah, I could talk about the custom authentication first and then I'll kind of show you how it works. So yeah, so yeah, so sometimes like you don't want to use the provider that we give you or you want to use a authentication provider that we actually don't support. We actually give you a way of integrating with any authentication provider that is compatible with OpenID Connect and it's actually really easy to actually set up that configuration. So yeah, I see that you're showing kind of like the page for that right now. That's where we kind of walk through how you wouldn't actually set up authentication and there's actually a separate page a little bit down on the menu there on the left side for setting up custom authentication. So that's what we're going to be talking about today. And yeah, so we have like full instructions on basically setting it up for the major providers like Facebook and all those things. We also have a tab for OpenID Connect as well. So that will basically allow you to add almost any modern identity provider today. And we've got here Azure AD, Apple, Facebook, GitHub, Google, Twitter, OpenID Connect and it comes along with some specific environment variables that you need or settings and then a little bit of a JSON here for your config file. Yeah, so like on my screen I can actually show you that config file. So this is just like a pretty typical static web app repository. I have a folder that's got my front end resources in it. It literally is a bunch of static assets in this case and a lot of you've been using a front end framework and I have some APIs that I'll talk about a little bit later. So here, so the only thing that you need to do to kind of configure a custom auth provider is to add an auth section. And you can basically, you kind of have to grab all this information from the provider. So in the case of Active Directory, you need the like the basically the URL to your tenant as well as you have to kind of configure a couple of application settings. So these are just names of application settings that actually has my client ID and my client secret. This way I'm not actually source controlling the client ID and secrets themselves. Yeah, so I'm sending those up to be read at runtime by the service. And this is all I need to do to actually enable that the open ID connect or actually does not open ID connecting provider. This is like just my own custom configuration of Azure Active Directory. And quite often you wanna do this because the one that we provide to you that the open Azure Active Directory provider that we give you allows anyone to log in. So as long as you have a Microsoft organization account or a personal account, you can log into that one. So we make that really easy for you to kind of have your end users to log in. But quite often you want to restrict your, you know, the folks that can log into maybe everyone that's on your Active Directory tenant or maybe even a subset of that, you know, maybe like certain security groups only, you only want to allow those folks to log in. We kind of allow you to do that by setting up your own app registration like I have on the screen here. Cool. One question about that then, is there a way that I can restrict access to my static web app? Specifically, I guess limit who can get there based on these type of roles that we create. Yeah, definitely we can. And this is actually a good lead-in to this demo here about some of the new capabilities that we added for this. So this is the site that I was just looking at here. So I've kind of set it up. When I navigate to it, it's, you know, I'm not logged in. So I can, you know, I'm kind of just printing out like what's, you know, like my login information. In this case, I'm not logged in. So I'm not showing anything. And by the way, after the callout, this is, you know, like I designed this page 100% myself, if you can believe it, using 100% technology that was available in 1995 when I first started writing web pages. So nothing has changed. So now when I click on login, I don't know if it's easy to, actually maybe I'll right click on it and copy link. Not that it's going to make it any bigger. Actually, I'll paste it into maybe here. Sure. Nope. Control and in a browser, doesn't actually open a thing. No, maybe that won't work for me. I'll just kind of paste it in here. Hopefully people can see it. Maybe not. But I'm actually navigating to a magical path called .auth slash login slash AAD. And that kicks off the authentication flow in static web apps. In this case, it's going to try to log the user and using Active Directory, which I have configured as a custom provider in this case. So if I click on that, it's going to go ahead and log me in. I think I have to go through, I don't know, multi-factor authentication here. And it's really multi. And anybody who's seeing that 50, that's not for you. So don't even bother trying. We've got a great security process for our Azure demo accounts. Yeah, I'm going through the multi layers of approval processes that we have to go through every time we open a Y-page here at Microsoft. But I think up through, okay, there you go. So I'm logged in. You can see I have more information. I found out last night that I probably didn't want to show this on the screen. So I updated the code to plan it out. But you can actually find a lot of stuff from the provider. So you as an application developer can actually find out who these people are. And yeah, it's that easy to log in. You might see here that I have some user roles. These two roles here are built in. So the anonymous roles, anonymous role and the authenticated role are built in. So when I'm logged in on both of those. But you can see here, I actually have a role called reader. So I want to talk about where this comes from because this is like a new capability that we shipped a few months ago. It's currently in preview that allows you to actually control what roles your users are in when they sign on to your application. And what you can use these roles for is that you can set up these routes so that you can say that for certain routes only admins can log in, right? So in this case, I am logged in as a reader or I'm not in the admin role. So when I click on the page that's only for admins, I get the 403 page. So, but I can access this page that's available for all authenticated users. So how I did this is by using this thing called a roles source function. I think that might be the official name for it. I think like it is a function that returns roles based on the person logging in. So all you have to do is add this role source property to your authentication configuration. And then every time somebody logs in, it's gonna turn around and call this API that's set up in my application. And in this case, it's a function, it's an HTTP function called getRoles. And I'll show you that here. And it's just a plain, it's a regular HTTP function that you might write yourself. Where is it? It's right here. And yeah, it's, but one interesting thing is that it gets passed basically this stuff here. So there's information that we got from the provider about this user. So now you can actually use this information to decide what roles this user needs to be in. So for instance, if you want to go and do a database lookup because that's where you kind of have your mappings between usernames and roles, for example, you can do that. If you want to call another API, you can do that. This example here actually takes the user's information from Active Directory and makes a call to the Microsoft Graph and say, hey, am I a member of certain groups? And then if I am, then put me into these roles in static web apps. So this function basically takes the person's logged in information and turns it into some roles that my application can use to kind of decide which roles that people are allowed to see or things like that. So I won't kind of go through the code here, but I'm literally just making a call to Active Directory or to Microsoft Graph. And I'm asking about whether or not the user is part of these two groups. And if they are, I'll put them in the corresponding group. And I'm just returning those. And that's how simple this function is. And then it gets called every time someone logs in. And that's how I am getting into the reader role here. I don't know how we're doing for time, but I can actually show you quickly how to, what happens if I put myself into another group. We're good on time. We got about good 15 minutes left or so before we need to wrap. Okay, but if there's any questions right now, we've got one right now for you to answer them while I kind of fumble around with my Active Directory. Will this Active Directory authentication strategy work if I use a static web app as a custom app within Microsoft Teams? Is a question we got from Milwaukee. As a custom app with Microsoft Teams. I don't know if Simone, you know the answer to this one. I don't know the answer, but I think that's a really good question that we're gonna take back and investigate. I would expect that it should work seamlessly, but I haven't tried that myself. Got you. So we have folks who work on Microsoft Teams who are trying to figure out what that story is between basically like can customers build Microsoft Teams apps using static web apps? So I know that they have figured out how to do it. I just don't know whether or not it's actually documented or whether there are any kind of gaps or any kind of like points that we should smooth over before we actually really tell people that you can do it. But I know that there's folks in the Microsoft Teams team, I guess, who are looking into this. Yeah, and I also know our good friend from Patrick Lamber from EasyLife and Experts Insights. They're actually building an application or a set of applications that are built within Teams with static web apps. So for sure they have explored this scenario and it should work well for them. Got you, got you. We've got a lot of comments today and I really, really appreciate that. Matter of fact, Nicholas wanted to share that he's using static web apps for an appearance model website, something to deliver to the customer that is not fully functional but gives them a chance to critique the look and feel. I think that sounds like a really great use case. Sometimes you need to stage something for a customer. You don't have to, you don't wanna put all the functionality in, you just want them to be able to tell how it looks. If it's just HTML, JavaScript or something like that or CSS, it sounds like static web apps is an ideal landing spot for that. Yeah, for sure. And I think we're also working on new features that support specifically these kinds of use cases. Like for instance, wanting to really quickly share something with the customer, for example, to give them access to see how things are going and review the latest version of a website. So look forward to see more things in that area. So I just wanna quickly go back to this demo here. I've added myself, I found the right page in static or in Active Directory to add myself to the admin group. And now when I log in, you can see that when I log in and hit that function and that function called Microsoft Graph and now Microsoft Graph is saying that, hey, I'm also a member of this admin group. So I'm now mapped to the admin role as well. And then now when I log in, or now when I click on the admin only page, I can see it. So I can see all the secrets. Very cool. We've got everything. This is a great demo, Anthony. It's really cool to see how all kind of comes together to build these like restrictive groups to be able to make sure that only the right people are getting to the right things within your static website. So I've got another question for you because we've got just so much time left and there's definitely another feature that I'd like to learn a little bit more about and that's durable functions. And so can I use Azure Durable functions or trigger functions with a static web app? Yeah, you can. So currently the managed function apps that we provide to can only support HTTP triggers. And those of you who have used Azure Functions, you'll know that Azure Functions actually supports many other triggers as well. You can trigger from queues, you can trigger from like Cosmos DB and things like that. And one of the trigger types, so kind of programming models that we have and Azure Functions is called Durable Functions, which allows you to kind of build these kind of programmatic serverless workflows that can run for a long time, hours or days or even months. And they can also do fan out, fan in or processing of things as well. It's really powerful. So we currently don't support that in the managed functions. So like that's the functions that you source control with your static web apps. But what we allow you to do is you can actually take those function apps that have these other triggers that we don't quite support yet in static web apps functions and deploy them as a separate function app. And then in static web apps, we allow you to go ahead and link to a function app. I don't know if I can- Right here in the documentation, I've got it up. Oh, there you go. That's a better screenshot than what I was gonna poke around and try to find you that screen. But yeah, so you can actually go to your static web app. It needs to be in the standard tier. And then you can say, hey, instead of using functions that are, source controlled in my repository, just use that other one that I already have in my subscription. And what it allows you to do is that instead of, when you access your static web app at slash API slash whatever, instead of it going to a, like the managed function app that we provide to you, you'll actually get routed to your function app that you have elsewhere. And that works. Gotcha. So I've got your screen back up. It looks like you've got a function over here. Do you wanna kind of talk a little through it? Yeah, so a function app is fairly simple. You, like I'm actually in VS code in the browser. So I don't have the static web apps extension installed. But if I were actually running this locally, I can actually, with a single command, scaffold out a function app for me. In my static web app project. And a function is really just a file. And you can see here, it's pretty simple. And it's literally just a function. Everything else are just kind of helper things. Yeah, so it's really easy to kind of create these things. You can have, you know, use it to create one endpoint or 10 or even more, depending on what your application needs. Gotcha. What I think is awesome about serverless APIs is that at the end of the day, when you're building your web application, and let's say, as I showed earlier, the sticker shop app, you want to potentially add a contact form page that calls your webhook or calls a service, a third-party service, like maybe Office 365 or a send grid. And you wanna be able to send emails directly from your application, but you need to store secrets. So at that point, using this thin layer as a serverless function to connect to third-party services is, it fits really well for front-end applications. Like I have to say that after working for a number of years with serverless, it just, it's very hard for me to justify having to spin up a server and build like ExpressJS routes or anything like that when I know that the cloud provider can manage the infrastructure for these serverless endpoints. And it includes a programming model that's actually relatively straightforward. And not only that, especially with durable functions, I think what's great is that there's also this implementation of certain abstractions that are useful on a day-to-day basis. So things like the fan-and-fan-out pattern where you have to send a bunch of work to different workers. Like if you have this maybe monthly email newsletter that you're sending out and you're sending it out to like thousands of customers, then you can basically make sure that you're fanning out that email. And then with durable functions, you can also check in and retry or check if there's any errors. So I think that's also great that you really have this benefit from serverless functions. Gotcha. So we're running low on time and that's fine because I only have really one more big question. And it's around the CICD part of all of this. One of the great things that I learned about Azure Static Web Apps is from the beginning, from the very, very launch of the product, you had CICD kind of in the built-in to the product, baked it. So we all know that if we've used it before, for those of you who don't, the out of the box was GitHub Actions. So you got to do all of your build and test all through GitHub Actions. You can go ahead and take a look at the actual workflow within GitHub Actions and make determinations on, well, let's have it published based on these types of triggers and that type of stuff. But you also added Azure DevOps support and I just wanna show a little bit of that documentation, kind of talk about it. There's a great tutorial that you can take a look at about publishing with Azure DevOps and I think and you can tell me the big difference is that the big major difference is obviously you're not using GitHub to manage the actual build process. You're going into here and you're changing the deployment details and specifying other and allowing you to kind of give all of your information about Azure DevOps. How have you seen adoption of using one over the other been in since like the addition of being able to use other as a where your deployment method is? Yeah, I think we've seen a very significant uptake in usage of Azure DevOps. What we're finding is that people don't wanna switch from Azure DevOps to GitHub or from one thing to another. So Azure DevOps is definitely one that has gotten probably the highest number of feedback that folks have asked us to add. So this is like what you kind of showed there is kind of like our first step to adding support for Azure DevOps. We definitely wanna have do more there, including, you know, hopefully making it easier for you to kind of create that Azure DevOps pipeline so you don't have to go and kind of copy paste from this tutorial here. And we're also kind of realizing that folks who use Azure DevOps actually have tend to use different workflows. A more kind of like a DevOps-y kind of a workflow where you build one, so you deploy it to multiple environments, which is actually a little bit different than what folks tend to do with Jamstack and kind of how we implemented our kind of default support in GitHub. Where you kind of have branch-based kind of models like that. So we're actually gonna work, we're actually working on how we can actually enable that workflow as well. So that you can have not only, you know, like a build pipeline, but also release pipeline that takes that same artifact and promotes it from environment to environment and have that be super smooth. You can do that today, but we wanna make that a lot easier for you. Well, if you hear in the background, the music reminding us that we're getting close to just being out of time. It's like the Academy Awards. Yes, I'm not trying to play off, but I wanted to give you a little bit of a tune to background everything as we kind of finish things up. So to kind of close out Azure Static Web Apps, a great place for you to put your Static Web Applications, not be as concerned about the infrastructure, being able to build really, really great applications without the headaches. And I just wanna learn a little bit more before we go. Simona, do you have anything interesting coming up that you wanna share that people can kind of check out and how they can get in touch with you on the internet? Oh, they can definitely find me on Twitter at Simona underscore quotient, that's my name, and I think it's necessary in the text here. And then in terms of what's coming up, we have tons of exciting things, but really where I want people to go is the GitHub Azure Static Web Apps repository and make sure to share your feedback with all of us, start discussions there, and let us know how you're using the product. We'd love to learn more from you. Gotcha, thank you so much, Simona. And Anthony, I know you just started a new role. I did. And I am very, very excited to hear about anything interesting you find, or you have that's coming up alongside starting a new role. Yeah, so I started a new role on the Azure Container Apps team. I'm still thankfully able to spend some time with Simona. I think I'll be very sad if I have to completely move away from Static Web Apps. So I'll still be doing a little bit with Static Web Apps. We have lots of good stuff planned for both services as well as Azure Functions as well. So stay tuned, find us on Twitter, stuff like that. Awesome. Never letting you go, Anthony. So don't worry about that. Ha, ha, ha. So that about does it for us today. I wanted to say thank you to you both. I really appreciate, especially Simona. I know it's a little later there and you're probably ready to get your evening wrapped up. I know I wanna get to my HBO Max and watch my stories. But I really do appreciate all this and it was great talking to you both, great learning more about these new things and Static Web Apps. And so until next time, let's give everybody, I'll put us in this mode, let's give everybody the big wave goodbye and say we'll see you soon. Thanks everybody for watching. We'll catch you at the next one, all right? Take care. See you all soon, bye. Bye.