[Spa] Spa proxy enhancements

[javiercn]

This issue tracks three small 'enhancements' to the SPA proxy experience since we would hopefully tackle them together.

1

As part of the changes to 6.0 we delay starting the SPA proxy until the first request arrives as opposed to previous versions where the proxy would start right when the pipeline was built.

In general, it should not matter as the first gesture the user does is going to be opening a browser to navigate to the app. However, it can shave some seconds. This suggestion superseeds #39314

We would add something like

        if (!await _spaProxyLaunchManager.IsSpaProxyRunning(context.RequestAborted))
        {
            _spaProxyLaunchManager.StartInBackground(...);

here (We would need to deal with the async nature by capturing the task and surfacing it later or something like that as well as managing our own cancellation internally).

2

Offer the option to keep the spa proxy running.

When we are in charge of launching the proxy, we also take care of stopping it when the .NET process stops. However, this can lead to a suboptimal experience, for example when using dotnet watch as it sometimes has to restart the process and that results in the proxy stopping and starting (which is cumbersome because it is time consuming).

We should add a KeepRunning option here and avoid launching the watch script here to stop the server.

3

Add a proxy timeout in the proxy config settings to ensure that the proxy responds timely when the request is cancelled on .NET

The fix is to add proxyTimeout: 3000 in https://github.com/dotnet/spa-templates/blob/main/src/content/Angular-CSharp/ClientApp/proxy.conf.js#L6 and https://github.com/dotnet/spa-templates/blob/main/src/content/React-CSharp/ClientApp/src/setupProxy.js#L24 and partially addresses #38917 (we still need to investigate the root cause, but we suspect it is something in node)

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[jepperaskdk]

Nice!
I think 2) would be a nice solution. Currently I run the ng-serve manually with a proxy.conf.json so I won't have to wait for ng-serve to get started in between restarts. This is by far the most effective, and 2) would mimic that.
It takes about 15 seconds on my machine (on a fresh dotnet new angular) when a "rude edit" is made during dotnet watch run, and until the SPA is ready (maybe mostly the fault of Angular).