Dapr and Aspire what should be the expectation #2735
-
|
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. Currently, we are trying to define the service we wanna use inside of Aspire. And then publish them as components/building blocks in dapr. 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:
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:
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 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
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. 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! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@philliphoff is there any progress on that idea since then? With the release of Aspire 9 much changed, and this idea from above sounds now more realistic than ever before. I do currently try out locally how to improve the dapr integration. |
Beta Was this translation helpful? Give feedback.
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…