More advanced Dapr example

[sclarke81]

I'm new to Dapr (and Aspire!) so I may be missing something, but I've read everything I can find without finding an answer. I'm starting a new project using microservices and I'd like to use Aspire and Dapr (and Radius?) with the goal of easy local development and production deployment to Kubernetes. I can't find any examples that use Radius. The examples I can find using Aspire and Dapr only use pubsub and state components; there's no more detailed examples using other components such as configuration. I'm also unclear on how to provide Dapr config for production. The AspireWithDapr example in aspire-samples uses the default pubsub or state component if they exist, otherwise the config for the in-memory component is created and used. So where/when do we provide the prod config? Will configuration components be added to Aspire.Hosting.Dapr or should we use AddContainer, AddDaprComponent and a yaml config file to add them to the AppHost? I'd really appreciate any guidance on the best practice and intended workflow here. I'm happy to provide feedback as well as this is something I'm currently working on.

[davidfowl]

I can't find any examples that use Radius

Aspire has no support for radius.

So where/when do we provide the prod config?

This isn't customizable at the moment. The dapr API for the component support isn't fully featured as yet and needs to be fleshed out more.

cc @philliphoff

[sclarke81]

I can't find any examples that use Radius

Aspire has no support for radius.

Sorry if I got the wrong end of the stick, but I thought I'd read that the intent was they'd play well together? So we could use Aspire for local dev and then use the Aspire manifest with Radius for deployment.

So where/when do we provide the prod config?

This isn't customizable at the moment. The dapr API for the component support isn't fully featured as yet and needs to be fleshed out more.

It'd be great to understand the intent here. I'm guessing it'd be to define the Dapr components in Aspire and have it output the config? I've been playing today and created an overload of AddDaprComponent that takes a path to a Dapr config file. It reads the config file and uses that to set the name and type of the Dapr component as well as adding a container (I'm just experimenting with configuration.redis). This feels like it's the wrong way around though.

I do understand that this is all new and may not be all fleshed out yet, but I'd like to understand the bits that are working together, where the gaps are and where it's headed so I can align our solution with the current trajectory.

[davidfowl]

Sorry if I got the wrong end of the stick, but I thought I'd read that the intent was they'd play well together? So we could use Aspire for local dev and then use the Aspire manifest with Radius for deployment.

Sure you can do that, I'm just saying there's no first class support to produce radius assets from an aspire application apphost

[philliphoff]

There's what's here now and what I'd like to get to given sufficient time. What's here now is that, except for the dynamic configuration of "generic" in-memory state store and pub-sub component support, configuration of Dapr components in Aspire still require defining and pointing to component YAML files, much like using Dapr without Aspire today. The in-memory component support was a step toward a more dynamic component model where those YAML files are generated under the covers based on references to the underlying DB, service, etc.

I'd love to eventually see something like:

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

var daprStateStore =
     builder
        .AddDaprStateStore("my-state-store")
        .AddReference(cache);

builder
    .AddProject<Projects.AspireSample_Web>("webfrontend")
    .AddDaprSidecar()
    .WithReference(daprStateStore);

builder.Build().Run();

However, there are a lot of state store, pub-sub, and binding components supported today by Dapr, and customers all use a different subset. There is a considerable amount of work to have dynamic configuration support for that subset of components likely to satisfy the bulk of Dapr customers. At the moment, other priorities prevent me from contributing to Aspire as much as I would like so I've not been able to go further down that path.

(There's also considerably more that could be done on the deployment side for Dapr-based Aspire applications; I was only able to scratch the surface of ACA deployment via Azure Developer CLI.)

[DamianEdwards]

Moving to dotnet/aspire as this isn't directly a samples issue

[searus]

Hi, one place I'm struggling with in code and documentation is how to specify a dapr state store as the dapr actor state store. Is this possible?