A modern application is rarely a single project: an API, a frontend, a database, a cache, perhaps a queue. Starting them all, wiring them up and understanding what happens between them is tiring. Aspire (born as .NET Aspire) solves exactly this.

The AppHost

A special project describes in C# the application's resources and how they are connected:

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");
var db = builder.AddPostgres("postgres").AddDatabase("catalog");

var api = builder.AddProject<Projects.Catalog_Api>("api")
    .WithReference(db)
    .WithReference(cache);

builder.AddProject<Projects.Shop_Web>("web")
    .WithReference(api);

builder.Build().Run();

At startup Aspire creates the necessary containers, passes connection strings and service addresses to the projects, and opens a dashboard.

The dashboard

Logs, distributed traces and metrics for every service in a single interface. You can watch a request travel through frontend, API and database, with the timing of each step: finding a bottleneck becomes a matter of minutes.

Service defaults

A shared project applies the same baseline settings to every service: OpenTelemetry, health checks, HTTP call resilience and service discovery. Each project enables it with one line, builder.AddServiceDefaults().

And in production?

Aspire is mainly designed for local development, but the application model can be used to generate deployment configuration for containers and the cloud. Even without using it in production, the gain during development and integration testing is significant.