Quando Microsoft ha presentato .NET Aspire, molti sviluppatori hanno iniziato a chiedersi se fosse una versione proprietaria di Dapr.

Dapr (Distributed Application Runtime) è un runtime open source progettato per semplificare la realizzazione di applicazioni distribuite. Descrizione che possiamo tranquillamente accostare anche a .NET Aspire, dove sta la differenza? Sono veramente due facce della stessa medaglia?

La confusione è comprensibile: entrambe semplificano lo sviluppo di applicazioni distribuite, entrambe offrono strumenti per la comunicazione tra servizi e entrambe migliorano l'esperienza di sviluppo di architetture moderne. La realtà è però molto diversa. Aspire e Dapr operano a livelli differenti e, nella maggior parte dei casi, possono essere utilizzati insieme anziché considerati come alternative.

L'idea alla base di Dapr è fornire una serie di building block (pacchetti che ricevono input e restituiscono un output) riutilizzabili che permettono agli sviluppatori di concentrarsi sulla logica di business senza dover gestire direttamente infrastrutture, broker di messaggistica o sistemi di persistenza.

L'architettura Dapr si basa su sidecar: ogni applicazione comunica con un processo Dapr locale che si occupa di interagire con le risorse esterne (Redis, Kafka, RabbitMQ, Azure Service Bus, Cosmos DB, PostgreSQL, ecc.).

builder.Services.AddDaprClient();
// ..
app.MapPost("/orders", async ( DaprClient daprClient) => { 
  var order = new OrderCreated( Guid.NewGuid(), "PRD-001", 2); 
  // pubblicazione di un evento
  await daprClient.PublishEventAsync( "pubsub", "order-created", order); 
  return Results.Ok(order);
});

Questo approccio rende l'applicazione indipendente dalla tecnologia sottostante. Tra i principali building block offerti da Dapr troviamo quelli che si occupano di messaggistica, State Management, Secrets Management, Workflow.

.NET Aspire, a differenza di Dapr, non introduce nuovi building block applicativi, l'obiettivo principale è migliorare la developer experience. Come spiegato all'interno degli script precedenti, permette l'orchestrazione locale dei servizi, configurazione centralizzata, dashboard unificata, provisioning delle risorse.

//AppHost
var rabbitMQConnection = builder.AddRabbitMQ("RabbitMQConnection", username, password);

builder.AddProject<Projects.myProject>("mio-progetto")
  .WithReference(rabbitMQConnection)
  .WithEnvironment("RABBITMQ_USERNAME", username)
  .WithEnvironment("RABBITMQ_PASSWORD", password)
  .WithEnvironment("RABBITMQ_TOKEN", token);

Anche se hanno delle funzionalità in comune, è da ricordare che Aspire e Dapr affrontano problemi differenti: il primo si occupa principalmente dell'ambiente di esecuzione e della produttività dello sviluppatore, mentre il secondo fornisce funzionalità distribuite all'applicazione.

Esistono comunque alcune aree comuni, come ad esempio il Service Discovery che in Aspire è gestito tramite AppHost e fornisce gli endpoint direttamente ai servizi, mentre in Darp si utilizza il proprio runtime e sidecar per invocare altri servizi.

Nei prossimi script costruiremo un'applicazione che utilizzando il meglio dei due mondi permetterà di ottenere un ecosistema stabile e mantenibile.