Aspire in development
The problem it solves
The Starter is a graph: PostgreSQL, Redis, RabbitMQ, a mail catcher, a migration runner, an identity host, an API, a gateway and four front-end apps. Starting them by hand, in the right order, with matching ports, connection strings and secrets, is a page of instructions that drifts from reality.
.NET Aspire's AppHost describes that graph in C#
(back/Blouppy.Aspire.AppHost/Program.cs): containers, projects, npm apps, which waits
for which, which reference which. One command starts all of it, injects the connection
strings, and opens a dashboard with every service's logs, traces and metrics.
The same graph serves the end-to-end suite: Aspire.Hosting.Testing builds it in
process, so the tests run against real PostgreSQL, RabbitMQ, identity host, API and
gateway.
Blouppy.Aspire.ServiceDefaults adds what every service shares: OpenTelemetry, health
checks, resilience handlers and service discovery.
What it costs
- Docker on every developer machine.
- Persistent containers keep data between runs, which is fast — and means a password set after the first run is ignored (see Troubleshooting).
- One more tool to learn, with its own release cadence.
What you can relax
- Aspire is for development and tests only. Production runs on Docker Compose
(
deploy/), and the services read ordinary configuration: nothing in them depends on Aspire being there. - Run a piece alone. The migration runner, the API or a front-end app can each run
with
dotnet runornpm run dev, given the connection strings.