This was good. I've noticed on youtube, Azure created tutorials NEVER show the network traffic developer console of the browser. Like they're afraid someone will get lost. I'd recommend opening the browser traffic so we can understand what the API is calling from the browsers perspective. It would be much more clear.
At this point, is it better to host your (SPA frontend + dotnetcore web api backend) application on Azure static web apps rather than Azure App Service? What are the pros and cons.
Not sure I understand the value in this. Is it simply about avoiding CORS issues? So the SWA is effectively proxying the API request? I guess that means you could restrict network access to the API as it would not longer need to have a public endpoint, provided the SWA can access it. And it would fix any CORS issues. Although I'm assuming that a lot of public APIs don't have strict CORS configuration anyway as they intended to be consumed by any application. I guess it helps if your API is supposed to be private and only consumed by a single app. Or am I missing something?
You pretty much hit the nail on the head. It's meant to simplify Auth and CORS. It also simplifies frontend development as you don't need to manage server URLs, you can simply make a call to 'api/endpoint' and your request will be proxied to the same path on the backend. This integrates nicely with services like Front Door and other traffic management solutions to automatically route traffic depending on load and latency.
Is there a way to access x-ms-client-principal header when developing locally using @azure/static-web-apps-cli ? Or what should I do for local development to authorize and get user info in backend API?
Hi, thanks for the great session! Regarding the Twitter Auth that was mentioned... Can I use role-based authZ with this like with AAD? I.e. I have appRoles enabled for the API app registration and users need to be assigned a role for access... But the twitter user principal is not in AAD and therefore I cannot assign a role to it.
You can find the resources in this blog article: techcommunity.microsoft.com/t5/apps-on-azure-blog/use-static-web-apps-api-and-api-management-authorizations-to/ba-p/3603755
I like what I'm seeing but I think of Azure Static Apps as a nice solution because it's simple. As soon as you introduce APIM , there's the cost, the challenges to deploy it using infrastructure as a service, and all the other features you drag along that you won't be using.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
This was good. I've noticed on youtube, Azure created tutorials NEVER show the network traffic developer console of the browser. Like they're afraid someone will get lost. I'd recommend opening the browser traffic so we can understand what the API is calling from the browsers perspective. It would be much more clear.
Really enjoyed this episode of Azure Fridays, Annina is so passionate about the demo and explained it really well.
At this point, is it better to host your (SPA frontend + dotnetcore web api backend) application on Azure static web apps rather than Azure App Service? What are the pros and cons.
How might this work if APIM is placed behind Front Door and Application Gateway?
Not sure I understand the value in this. Is it simply about avoiding CORS issues? So the SWA is effectively proxying the API request? I guess that means you could restrict network access to the API as it would not longer need to have a public endpoint, provided the SWA can access it. And it would fix any CORS issues. Although I'm assuming that a lot of public APIs don't have strict CORS configuration anyway as they intended to be consumed by any application. I guess it helps if your API is supposed to be private and only consumed by a single app. Or am I missing something?
You pretty much hit the nail on the head. It's meant to simplify Auth and CORS.
It also simplifies frontend development as you don't need to manage server URLs, you can simply make a call to 'api/endpoint' and your request will be proxied to the same path on the backend. This integrates nicely with services like Front Door and other traffic management solutions to automatically route traffic depending on load and latency.
Is there a way to access x-ms-client-principal header when developing locally using @azure/static-web-apps-cli ? Or what should I do for local development to authorize and get user info in backend API?
did you ever figure this out?
Wondering same
That’s my sister !!!
Cant be! She is my sister!! Are you my brother?
She’s my brother
She's mine
Confident ❤
Hi, thanks for the great session! Regarding the Twitter Auth that was mentioned... Can I use role-based authZ with this like with AAD? I.e. I have appRoles enabled for the API app registration and users need to be assigned a role for access... But the twitter user principal is not in AAD and therefore I cannot assign a role to it.
Also how do I configure it to only allow AAD logins from my tenant?
Could we get a link to the sample front-end and back-end source-code shown in the video? Thanks!
Yesss
You can find the resources in this blog article: techcommunity.microsoft.com/t5/apps-on-azure-blog/use-static-web-apps-api-and-api-management-authorizations-to/ba-p/3603755
This is awesome! This is going to be massive!
I like what I'm seeing but I think of Azure Static Apps as a nice solution because it's simple. As soon as you introduce APIM , there's the cost, the challenges to deploy it using infrastructure as a service, and all the other features you drag along that you won't be using.
This is great, thank you!
This is fantastic! Thank you and well done!
Very well explained.
Nice episode, she is passionate and excited to explain and keeps it simple too.
Awesome!
Super cool
"Oh, wait for it!!!" XDDD
So are static web appa static? Or able have dynamic content? 😂
Franca SP Brasil.
Handsome man