microsoft · IEvangelist · Apr 8, 2026 · Apr 7, 2026 · Apr 8, 2026 · Apr 8, 2026
@@ -364,7 +364,7 @@ await builder.build().run();
 In this example:
 
 1. The `frontend` resource builds inside its container, producing compiled JavaScript, CSS, and HTML.
-2. During publish, Aspire copies those files from the frontend container into the `api` container at `./wwwroot`.
+2. During publish, Aspire copies those files from the `frontend` container into the `api` container at `./wwwroot`.
 3. The resulting `api` container includes both the API code and the frontend static assets, ready to serve the full application.
 
 ### Serve a frontend from YARP

@@ -43,7 +43,7 @@ This section demonstrates practical migration scenarios you'll likely encounter
 
 ### Multi-service web application
 
-This example shows a typical three-tier application with frontend, API, and database.
+This example shows a typical three-tier application with a frontend, API, and database.
 
 **Docker Compose example:**
 

@@ -43,14 +43,14 @@ Why is modality important when it comes to the AppHost's execution context? This
 - Database: PostgreSQL
 - Cache: Redis
 - AI service: Ollama or OpenAI
-- Back end: ASP.NET Core minimal API
-- Front end: React app
+- Backend: ASP.NET Core minimal API
+- Frontend: React app
 
 Depending on the mode, the AppHost might treat these resources differently. For example, in run mode, the AppHost might use a local PostgreSQL database and Redis cache—using containers, while in publish mode, it might generate deployment artifacts for Azure PostgreSQL and Redis Cache.
 
 #### Run mode
 
-The default mode is run mode, which is ideal for local development and testing. In this mode, the Aspire AppHost orchestrates your application model, including processes, containers, and cloud emulators, to facilitate fast and iterative development. Resources behave like real runtime entities with lifecycles that mirror production. With a simple <kbd>F5</kbd>, the AppHost launches everything in your app model—storage, databases, caches, messaging, jobs, APIs, front ends—all fully configured and ready to debug locally. Let's considering the app model from the previous section—where AppHost would orchestrate the following resources locally:
+The default mode is run mode, which is ideal for local development and testing. In this mode, the Aspire AppHost orchestrates your application model, including processes, containers, and cloud emulators, to facilitate fast and iterative development. Resources behave like real runtime entities with lifecycles that mirror production. With a simple <kbd>F5</kbd>, the AppHost launches everything in your app model—storage, databases, caches, messaging, jobs, APIs, frontends—all fully configured and ready to debug locally. Let's considering the app model from the previous section—where AppHost would orchestrate the following resources locally:
 
 import ThemeImage from '@components/ThemeImage.astro';
 

@@ -112,7 +112,7 @@ Before you begin, ensure you have the following installed:
     pnpm dev
     ```
 
-    This starts the Vite development server for the front end and provide hot-reload capabilities.
+    This starts the Vite development server for the frontend and provide hot-reload capabilities.
 
 1. View the site locally
 

@@ -880,7 +880,7 @@ Aspire speaks many languages — thanks to these communities.
       <LicenseBadge title={licenseTitles.nodejs} />
     </div>
     <p>
-      The JavaScript runtime that enables Aspire to orchestrate front-end and
+      The JavaScript runtime that enables Aspire to orchestrate frontend and
       full-stack JS apps.
     </p>
     <div class="thanks-card-links">
@@ -1016,7 +1016,7 @@ Aspire speaks many languages — thanks to these communities.
     </div>
     <p>
       The typed superset of JavaScript that powers Aspire's TypeScript AppHost
-      and front-end tooling.
+      and frontend tooling.
     </p>
     <div class="thanks-card-links">
       <a href="https://www.typescriptlang.org" class="thanks-link-project">
@@ -1285,7 +1285,7 @@ The tools that power this very website.
     </div>
     <p>
       The fast, disk-space efficient package manager that builds the aspire.dev
-      front end.
+      frontend.
     </p>
     <div class="thanks-card-links">
       <a href="https://pnpm.io" class="thanks-link-project">

@@ -200,7 +200,7 @@ export const communityVideos = [
     href: 'https://youtu.be/dftmYBuZOLA?list=PL2E-vlKoo_v2dgxPizLVtdxvurOHvd8_h&t=341',
     title: 'Microservices: Aspire & Blazor SSR',
     description:
-      'Codewrinkles builds a microservices app, orchestrated with Aspire and using Blazor SSR on the front end.',
+      'Codewrinkles builds a microservices app, orchestrated with Aspire and using Blazor SSR on the frontend.',
     tags: ['Community', 'Blazor', 'SSR'],
   },
   {

@@ -121,8 +121,8 @@ You can also obtain the login token from the container logs. For more informatio
 
 The **Resources** page is the default home page of the Aspire dashboard. This page lists all of the projects, containers, and executables included in your Aspire solution. For example, the starter application includes two projects:
 
-- **apiservice**: A back-end API project built using Minimal APIs.
-- **webfrontend**: The front-end UI project built using Blazor.
+- **apiservice**: A backend API project built using Minimal APIs.
+- **webfrontend**: The frontend UI project built using Blazor.
 
 The dashboard also provides essential details about each resource:
 

@@ -70,7 +70,7 @@ For more information, see [Aspire dashboard configuration](/dashboard/configurat
 
 ## Architecture
 
-The dashboard user experience is built with a variety of technologies. The frontend is built with [Grpc.AspNetCore](https://www.nuget.org/packages/Grpc.AspNetCore) NuGet package to the resource server. Consider the following diagram that illustrates the architecture of the Aspire dashboard:
+The dashboard user experience is built with a variety of technologies. The frontend communicates with the resource server over gRPC using the [Grpc.AspNetCore](https://www.nuget.org/packages/Grpc.AspNetCore) NuGet package. Consider the following diagram that illustrates the architecture of the Aspire dashboard:
 
 <ThemeImage 
   light={architectureDiagramLight}

@@ -52,8 +52,8 @@ If you only add a Vite or JavaScript app and reference backend services, Aspire
 
 | Model                                  | Production entrypoint      | Aspire publish API          | Best for                                                                          |
 | -------------------------------------- | -------------------------- | --------------------------- | --------------------------------------------------------------------------------- |
-| Backend serves frontend                | API or web server          | `PublishWithContainerFiles` | Apps where one service serves both the API and the frontend                       |
-| Reverse proxy serves frontend          | Reverse proxy              | `PublishWithStaticFiles`    | Apps that want a gateway or BFF in front of APIs and static frontend assets       |
+| Backend serves frontend               | API or web server          | `PublishWithContainerFiles` | Apps where one service serves both the API and the frontend                      |
+| Reverse proxy serves frontend         | Reverse proxy              | `PublishWithStaticFiles`    | Apps that want a gateway or BFF in front of APIs and static frontend assets      |
 | Static frontend calls backend directly | Static site + separate API | Custom / less integrated    | Apps that intentionally keep frontend hosting separate and can manage CORS/config |
 
 <Aside type="caution">

@@ -84,15 +84,15 @@ A pipeline step represents a discrete unit of work in the application pipeline.
 Each step has:
 
 - **Name**: A unique identifier for the step
-- **Action**: The work to be performed during deployment  
+- **Action**: The work to be performed during deployment
 - **Dependencies**: Other steps that must complete before this step runs
 - **Resource context**: Access to the application's resource model and configuration
 
 Pipeline steps operate at different levels of granularity. For example, when deploying a typical web application with a frontend, API service, database, and storage, the pipeline might include:
 
 **Infrastructure steps** (can run in parallel):
 - `provision-cosmosdb`: Provision the CosmosDB database
-- `provision-storage`: Provision Azure Storage account  
+- `provision-storage`: Provision Azure Storage account
 - `provision-aca-env`: Provision Azure Container Apps environment
 - `provision-container-registry`: Set up the container image registry