Refine the Dapr Sidecar API

[FullStackChef]

Related to an existing integration?

Yes

Existing integration

CommunityToolkit.Aspire.Hosting.Dapr

Overview

Revisit and refine the Dapr sidecar API to ensure it integrates smoothly with the overall builder pattern without breaking the chaining mechanism.

Usage example

With the release of CommunityToolkit 9.3 the following will be possible

var redis = builder.AddRedis("redis").WithRedisInsight();

var stateStore = builder.AddDaprStateStore("statestore").WithReference(redis); // <- Reference an aspire resource

var consumerId = builder.AddParameter("consumerID");

var redisPassword = builder.AddParameter("redisPassword", true);

var pubSub = builder.AddDaprPubSub("pubsub")
                    .WithMetadata("redisHost", "localhost:6379") // <- Ability to specify a metadata value
                    .WithMetadata("redisPassword", redisPassword) // <- Ability to specify a metadata secret 
                    .WithMetadata("consumerID", consumerId) // <- Ability to specify a metadata value
                    .WaitFor(redis);

From here it would be good to refine the dapr sidecar api

var daprSidecar = builder.AddDaprSidecar("sidecar") // <- Create a dapr sidecar
                         .WithReference(stateStore) // <- reference a dapr component
                         .WithReference(pubSub); // <- reference another dapr component

builder.AddProject<Projects.CommunityToolkit_Aspire_Hosting_Dapr_ServiceA>("servicea")
       .WithReference(daprSidecar) // <- reference the sidecar
       .WaitFor(redis);

builder.AddProject<Projects.CommunityToolkit_Aspire_Hosting_Dapr_ServiceB>("serviceb")
       .WithReference(daprSidecar) // <- Should this be allowed or trigger an error?
       .WaitFor(redis);

and for Azure:

var daprSidecar = builder.AddAzureDaprSidecar("sidecar") // <- Create an azure dapr sidecar
                         .WithReference(stateStore) // <- reference a dapr component
                         .WithReference(pubSub); // <- reference another dapr component

builder.AddProject<Projects.CommunityToolkit_Aspire_Hosting_Dapr_ServiceA>("servicea")
       .WithReference(daprSidecar) // <- reference the sidecar
       .WaitFor(redis);

builder.AddProject<Projects.CommunityToolkit_Aspire_Hosting_Dapr_ServiceB>("serviceb")
       .WithReference(daprSidecar) // <- Should this be allowed or trigger an error?
       .WaitFor(redis);

Breaking change?

Yes - but the existing api should be marked as deprecated and removed in a later version

Alternatives

Additional context

The approach above is based on that of the Orleans integration.

AddAzureDaprSidecar / AddDaprSidecar is based on the approach demonstrated by the Redis integration

Sidecar Reference:

• Option 1: Restrict the daprSidecar resource so that it can only be referenced by a single project. An analyzer could be implemented to enforce this rule to prevent accidental misuse and ensure clarity of sidecar ownership.
• Option 2: Allow the sidecar to be shared across multiple projects if each reference results in its own unique sidecar instance, because each reference would represent an individual sidecar instance, this would allow the sidecars to be defined by the combination of components rather than one for every resource which would be more verbose.

Help us help you

Yes, I'd like to be assigned to work on this item

[WhitWaldo]

I like the example you've got for what's coming with 9.3.

With regards to the later examples though, I'm inclined to suggest that the Dapr sidecar should not itself be independently referenceable given that each service within Dapr may have different components or different options applied to the same components (e.g. namespaces), in addition to exposing different ports.

[FullStackChef]

So just to clarify, are you saying that you don't like

var daprSidecar = builder.AddAzureDaprSidecar("sidecar") // <- Create an azure dapr sidecar
                         .WithReference(stateStore) // <- reference a dapr component
                         .WithReference(pubSub); // <- reference another dapr component

or the following:

BAD

var daprSidecar = builder.AddAzureDaprSidecar("sidecar") // <- Create an azure dapr sidecar
                         .WithReference(stateStore) // <- reference a dapr component
                         .WithReference(pubSub); // <- reference another dapr component

builder.AddProject<Projects.CommunityToolkit_Aspire_Hosting_Dapr_ServiceA>("servicea")
       .WithReference(daprSidecar) // <- reference the sidecar
       .WaitFor(redis);

builder.AddProject<Projects.CommunityToolkit_Aspire_Hosting_Dapr_ServiceB>("serviceb")
       .WithReference(daprSidecar) // <- Trigger an error "A sidecar resource can only be referenced by one application"
       .WaitFor(redis);

GOOD

var daprSidecar1 = builder.AddAzureDaprSidecar("sidecara") // <- Create an azure dapr sidecar
                         .WithReference(stateStore) // <- reference a dapr component
                         .WithReference(pubSub); // <- reference another dapr component

builder.AddProject<Projects.CommunityToolkit_Aspire_Hosting_Dapr_ServiceA>("servicea")
       .WithReference(daprSidecar1) // <- reference the sidecar
       .WaitFor(redis);

var daprSidecar2 = builder.AddAzureDaprSidecar("sidecarb") // <- Create an azure dapr sidecar
                         .WithReference(stateStore) // <- reference a dapr component
                         .WithReference(pubSub); // <- reference another dapr component

builder.AddProject<Projects.CommunityToolkit_Aspire_Hosting_Dapr_ServiceB>("serviceb")
       .WithReference(daprSidecar2) 
       .WaitFor(redis);

[oising]

What is an "azure" dapr sidecar with respect to a regular one? If you mean the former would be dapr in ACA, wouldn't this just be a distinction made by the publishing target, and not something you need to put in the apphost?

[FullStackChef]

@oising its the same with the sql and redis integrations which expose Add and AddAzure methods

Ultimately there are additional packages required for supporting publishing to azure and the alternative to this separation is bloating the main package

An alternative to this is what I've currently done, which was to reference shared code files in two packages

• Hosting.Dapr
• Hosting.Azure.Dapr

This still requires an explicit change but it's at the package level rather than the api level

The downside to this is that installing both packages causes conflicts so you still have to make an upfront choice.

Additionally it would limit the ability to build component level integrations that can be shared across the two

[oising]

I'm not really following the distinction. Mssql and azure Sql are genuinely two distinct products with differing features, as are azure redis and redis. Dapr is... Dapr, no? It seems like an unnecessary abstraction/complication IMHO

[FullStackChef]

You could be right, which of the differences between sql /redis and their azure counterparts require the difference in apphost registration (I'm using the same client packages and code in my applications)?

You are welcome to contribute an alternative approach, this is the best I could come up with on my own

[oising]

@FullStackChef Ping/DM me on discord, Brett -- might be easier to chat about the challenges there in real time.

[github-actions]

We have noticed this issue has not been updated within 21 days. If there is no action on this issue in the next 14 days, we will automatically close it. You can use /stale-extend to extend the window.

[oising]

/stale-extend

[WhitWaldo]

I like that the "AddDaprPubSub" creates a standalone referenceable object I can include in a Dapr sidecar, but I don't think var daprSidecar = builder.AddDaprSidecar() is necessarily a great addition as each project should never have more than one and they should each be configured separately from one another (e.g. different ports, different components, different configurations). The only exception to this I can think of would be having a separate reference for production vs local development, but even then, that's going to be more a distinction in the components themselves than the Dapr configuration.

On the AddAzureDaprSidecar vs AddDaprSidecar discussion, I also don't follow the distinction. There are more opportunities to deploy Dapr in Azure than just ACA though it's the initial route taken by Aspire. I think I'd prefer just having AddDaprSidecar and having the deployment work out that we're deploying to Azure and work out the deployment target itself without having a potentially confusing distinction.

[FullStackChef]

I will be revisiting this branch later today and will take a look