Add Preview 6 release note: Blazor Gateway backend API proxying#10481
Conversation
Document the .NET 11 Preview 6 capability where the dev-time Blazor Gateway proxies a standalone Blazor WebAssembly app's HTTP calls to backend services via a built-in YARP reverse proxy, so the client calls the backend same-origin with no CORS (dotnet/aspnetcore#67048). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e18854a-0f22-46db-b8e7-ed9a45106d9f
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
There was a problem hiding this comment.
Pull request overview
Adds documentation to the .NET 11 Preview 6 ASP.NET Core release notes describing new Blazor Gateway behavior for proxying backend API calls (via YARP) to avoid browser CORS requirements during development.
Changes:
- Adds a new release note section describing Blazor Gateway backend API proxying and no-CORS behavior.
- Adds a table-of-contents entry and includes a
launchSettings.json-based configuration example plus a link to a full sample.
| } | ||
| ``` | ||
|
|
||
| With this configuration the WebAssembly app calls its own origin (for example `Http.GetFromJsonAsync<WeatherForecast[]>("api/weather")`), the Gateway matches the `/api/**` route, and forwards the request to the backend at `http://localhost:5100/`. The Gateway also registers .NET service discovery, so a destination address can be a logical service name resolved from `services:<name>:<endpoint>:<index>` configuration in addition to a literal URL. |
There was a problem hiding this comment.
Fixed in d085eed. Removed the implementation-specific services:<name>:<endpoint>:<index> key format and replaced it with a link to the .NET service discovery docs plus a generic description.
I also verified this end-to-end: with a cluster destination address of http://backend, the Gateway proxied successfully (200) when service discovery resolved backend to the live backend, and returned 502 when the resolved target was unavailable — confirming the destination address can be a logical service name resolved at request time.
| Configure the proxy with a standard YARP `ReverseProxy` section describing the routes and clusters to forward. The Gateway runs as a separate process that reads this configuration from environment variables (or command-line arguments) rather than the app project's `appsettings.json`, so the simplest place to set it during development is the app's `launchSettings.json`: | ||
|
|
||
| ```json | ||
| "environmentVariables": { | ||
| "ASPNETCORE_ENVIRONMENT": "Development", | ||
| "ReverseProxy__Routes__weather__ClusterId": "backend", | ||
| "ReverseProxy__Routes__weather__Match__Path": "/api/{**catch-all}", | ||
| "ReverseProxy__Clusters__backend__Destinations__backend1__Address": "http://localhost:5100/" | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Fixed in d085eed. The snippet is now a valid JSON fragment showing the full launch profile (profiles -> http -> environmentVariables), and the lead-in text clarifies that these go in a launch profile's environmentVariables.
- Make the launchSettings.json example a valid JSON fragment (full launch profile with profiles -> http -> environmentVariables) so it is clear and copy-pasteable. - Replace the implementation-specific 'services:<name>:<endpoint>:<index>' key format with a link to the .NET service discovery docs and a generic description. Verified end-to-end that a logical service-name cluster destination resolves through the Gateway (200 with live backend, 502 when the service discovery target is unavailable). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e18854a-0f22-46db-b8e7-ed9a45106d9f
Summary
Adds a .NET 11 Preview 6 ASP.NET Core release note documenting that the dev-time Blazor Gateway can now proxy a standalone Blazor WebAssembly app's HTTP calls to backend services through a built-in YARP reverse proxy. Because the WebAssembly client makes only same-origin requests to the Gateway, which forwards them server-to-server, no CORS configuration is required on the client or the backend.
This capability landed in dotnet/aspnetcore#67048 (milestone 11.0-preview6), which made the Gateway's service discovery unconditional so YARP destinations resolve correctly. The Gateway itself was introduced in Preview 5; this note is the follow-up for the proxying feature, which was previously undocumented.
Changes
release-notes/11.0/preview/preview6/aspnetcore.mdReverseProxyconfiguration vialaunchSettings.jsonenvironment variables and the no-CORS behavior.Verification
11.0.100-preview.6.26359.118) using the sample at https://github.com/danroth27/AspNetCore11Samples (BlazorWasmFeaturescallingBackendApithrough the Gateway, confirmed noAccess-Control-Allow-Originheader and no CORS config).Note
The note is intentionally honest that the Gateway currently reads its
ReverseProxyconfig from environment variables / command-line args rather than the app project'sappsettings.json. Improving that config experience is tracked in dotnet/aspnetcore#67887.