Dapr and Aspire what should be the expectation

[paule96]

Hi Aspire team,

we currently started a new project and because we are far away from production, we decided to give Aspire an early chance. So far it works well for us. But we currently have a big pain point and that is the integration with dapr.
And it's not really about the implementation more on what can we expect from from it.

Currently, we are trying to define the service we wanna use inside of Aspire. And then publish them as components/building blocks in dapr.
The problem with this is, that for example, our state building-block should us a Postgres as a backend.
And as far as we can see, there is no way to give the daper state building block, the information where to find the postgres hosted by aspire.

var builder = DistributedApplication.CreateBuilder(args);

var stateDb = builder.AddPostgres("stateDb");

builder.AddDaprStateStore("stateStore", new()
{
    LocalPath = ""
});

Because the only option that is valid for the DaprStateStore component is a file path for a configuration file that lifes outside of Aspire.

And that's only one example of what currently leads us to something like this on every developer machine:

• dapr init
• setup Postgres
• setup some other building blocks
• then run the Aspire project

And with this, an old friend comes back to the project. "Port is already been used..."

So for me the vision of aspire is to just do this as a developer:

• run the aspire project

The question is, is this the vision for dapr too, and we are just not there yet, or is it a bit different? (like always define your dapr setup outside of aspire and then use it)

cc @philliphoff

[philliphoff]

The Dapr resource model in Aspire, in particular with respect to Dapr components, still has a lot of room for improvement. The initial goal was to have component auto-provisioning that "just worked" on run when applications were agnostic as to the exact kind of component being used. (E.g. just use the built-in Redis DB instance, if available, or fall back to an in-memory component if not.) Given that the Dapr building blocks are intended to allow applications to be agnostic with respect to their underlying dependencies, I still think that made sense.

That said, I think the next step is to help automate Dapr component setup for when the application (or, rather, the larger orchestration) does specify a specific underlying store (e.g. Postgres vs. Redis). In particular, this would be useful for deployment scenarios where, while the application itself may not care the type of state store used, the developer provisioning it in the Cloud does care.
What I'd like to eventually see is something along the lines of:

var builder = DistributedApplication.CreateBuilder(args);

var stateDb = builder.AddPostgres("stateDb");

// Configure a Dapr state store component to use the Postgres DB
var stateStore =
    builder
        .AddDaprStateStore("stateStore")
        .AddReference(stateDb);

// Configure the Dapr sidecar for this service to use the state store component 
var serviceA =
    builder
        .AddProject<Projects.ServiceA>("serviceA")
        .WithDaprSidecar()
        .AddReference(stateStore);

One of the questions will be whether the Aspire resource/reference will support this, as the Dapr component resource needs to know the exact type of the referenced resource, whereas the type is already known to applications and so they need only the connection string. I think it does, but I've just not had the time to experiment with it. As ever, there is always more to do than time and competing priorities allow. That said, thoughts about the direction of Dapr and Aspire, as well as contributions, are always appreciated!

[paule96]

Thank you! It's nice to read that our goal matches with vision. And yes time is always a challenge. I will discuss this next week with my team, and maybe we can find time to contribute a bit to this idea.