Plans for the Static Web Apps

[dansiegel]

Forgive me if this is a stupid question. I'm a bit stuck on understanding the purpose of the extension for Static Web Apps considering the note in the ReadMe:

(Note: this does not support deployment of a project to Azure Static Web Apps).

So if it doesn't support a deployment scenario what exactly the purpose of developing with this? I mean isn't the whole thing really only useful if we can deploy it?

[aaronpowell]

The goal of Aspire isn't to be seen exclusively as a pathway to deployment, it can be used as a deployment tool but it also has strengths as a tool that focuses on the developer inner loop.

Let's say you already have a deployment pipeline in your application, Aspire can still offer benefits in managing the resources locally to stand up databases, provide (local) service discovery, introduce consistency on resilience in HTTP retry and a standard approach to logging/tracing via OTEL. None of that would require you to change your deployment process, you'd just not run azd up against the app host at any point.

The SWA emulator integration came about because I work on that sort of a project at Microsoft. In it we have a Blazor admin system and an API backend + React frontend (deployed to SWA with Container Apps). This uses some AI resources and a PostgreSQL database that needs to be available to both the Blazor admin and API. Local dev is a cobbled together set of scripts to pull containers, ensure the networking is configured for "service discovery", create AI resources, and so on. It's a bit fragile but it works.

So, I want to use Aspire to simplify that, and one of the things I need to do is "simulate" SWA locally, which we were doing, but again, it required additional scripts to be run outside of VS to ensure everything starts.

And deployment is not a concern since we already have a large amount of IaC that handles that in ways that Aspire simply wouldn't be capable of, at least not presently.

Would I like the SWA integration to support deploying SWA resources? Yes, but currently Aspire is focused on deployment of container resources. You could have Aspire deploy everything except the SWA resource and just add that to the azure.yaml as a service directly if the desire was to deploy with azd and the app host.

[dansiegel]

What you're saying makes perfect sense. I don't know whether to say the docs belong solely to the responsibility of the Toolkit or to Aspire itself. But at the very least if the docs are done in Aspire itself, then I might suggest linking to them for the deployment concern.

In order to promote adoption I think it's important for people to get a better understanding of how to deploy the SWA while still integrating with the Aspire Dashboard in Azure and what they would need to do to configure the SWA to connect to the resources which come through automatically and particularly for Open Telemetry. Right now just kind of skipping over the topic makes it harder for people to adopt.

[aaronpowell]

If there's a lack of clarity on the role that deployment plays in how to approach Aspire, then that's something worth exploring with the overall Aspire docs. It's worth noting that the overview doesn't mention deployment.

Similarly, deployment to Azure compute resources that aren't into Azure Container Apps is beyond the scope of something we can tackle in the Community Toolkit. Hopefully Aspire and azd provide enough hooks that someone could deploy based off a manifest generated by Aspire, but that's beyond the scope of something we'd be able to tackle in the Community Toolkit. The process I outlined above is the theory on how it could work (customising azure.yaml and combining with what azd generates), but it's not something I've put into practice because I'm content with the separation between local development and deployment tooling for compute resources that fall outside of ACA.