What's the plan for parts of Aspire that overlap with dapr?

[atrauzzi]

My understanding right now is that while Aspire helps with setting up dapr sidecars, after that point, it ultimately treats dapr like an orthogonal concern.
This has been enough to let me get up and running locally and to start playing around with both. But, I end up with confusion or concerns around what the longer term implications of having both in a single project are.

Aspire and dapr both have opinions on things like service to service invocation/resolution, observability, and likely more that I'm just not fully mindful of yet.

When I configure my Program.cs, I'm going between two different sets of getting started guides. The first is for Aspire, which revolves mainly around ServiceDefaults. The second is from dapr, which is telling me to either configure their extensions on top of standard MS abstractions, or bind their ApiClient and target it from all my code.

Neither of these are necessarily problems in and of themselves, both are offering amazing functionality. But say I'm making a CLI utility for my project and it needs to both connect to my database and interact with dapr state stores. Once I've configured all the various application bootstraps for both Aspire and dapr in its Program.cs, what do I even type into the console to start that app? 😅

I know what dapr is going to want -- it's going to want a sidecar to wrap the program. But for Aspire, what would I be on the hook for to ensure that the database resource is fed in correctly?

Are there any thoughts around possibly elevating dapr to something more fist class in Aspires own DSL so that once dapr is enabled, Aspire prefers dapr for the things they have in common?

(@davidfowl, forgive the ping, but I'm curious to hear how you and the rest of the team are thinking about these things and how they could be simplified from a dev experience perspective.)

[davidfowl]

Dapr is a abstraction layer that promises to abstract your application's sdk dependencies using their sidecar. When using the dapr integration with aspire, aspire plays the role of coordinator and configurator (is that a word?), booting up side cars, hooking up dapr sidecar's telemetry and connecting dapr components to aspire resources (db, redis, etc), and configuring dapr deployments on ACA.

Aspire client integrations are not abstractions, they are glue, they let application code talk directly to the underlying service/db/cache etc. In that sense, the approaches are intentionally different and users can choose based on what kinds of tradeoffs they want to make in their applications.

I know what dapr is going to want -- it's going to want a sidecar to wrap the program. But for Aspire, what would I be on the hook for to ensure that the database resource is fed in correctly?

I'm not sure what you're asking. Aspire uses client libraries that .NET developers use today. Want to use postgres + EF, look at the integration docs for it https://learn.microsoft.com/en-us/dotnet/aspire/database/postgresql-entity-framework-integration?tabs=dotnet-cli.

Are there any thoughts around possibly elevating dapr to something more fist class in Aspires own DSL so that once dapr is enabled, Aspire prefers dapr for the things they have in common?

We're talking to the Dapr .NET client maintainers to consider including the aspire integration in their scope, so that it can evolve side by side with the Dapr .NET client. These discussions are still fresh, so there's no conclusion yet.

That said there's no plan to make it more first class than it is right now. Dapr will remain an optional integration that aspire users can choose to use.

That said, I do believe that the dapr integration could use a lot more love with respect to dapr components wiring up to aspire resources. There could even be dapr + aspire templates that shipped as part of that integration experience.

The core aspire team does not plan to build this though.

[atrauzzi]

I don't consider that fuzzy, I consider that to be a tradeoff that developers make.

I guess I'm just wondering why it has to be framed as a "tradeoff" at all? If someone chooses to use Aspire and dapr together, but both risk have overlapping functionality, the "opt-in" (dapr in this case) should be allowed to drive. Without creating ambiguity. Let's take the next point as an example here...

Unclear what you mean here. Aspire wires up the OTLP exporter to the dapr side car and the dapr side car emits telemetry that shows up in the dashboard. Anything beyond that there's been no work to support (is there something else?).

Yeah, so in my applications, I can work with ActivitySource. Aspire - helpfully - wires all that up and captures it. But does that flow through the dapr sidecar, or does it go directly to Aspire?
Another one is .WithReference, where Aspire is setting up visibility between containers, but when I'm using dapr, I don't need to worry as much about that because I'm able to use bindings. But I could easily see people mistakenly thinking that on top of configuring dapr, they also have to "mirror" that in Aspire.

Maybe it's just a matter of making it easier for people to understand what flavours they're invoking while writing in AppHost/Program.cs, so that they can clearly understand when two pieces aren't in the same sandbox and won't interoperate or be in any way aware of one another?

To a newcomer - or at least me - these can certainly be resolved individually. But it's time consuming to understand which parts are cooperating and which are - as you are saying, completely separate.

...on how to use an aspire application...

The parts that are covered are covered well so far, but I think there are still structural questions people are going to need answered. The kind of stuff I might get asked when trying to present this technology to higher ups 😅. The ones I'm struggling with right now aren't "how to use Aspire 101", but more about what an Aspire-enabled app is once it's built and delivered outside of Aspire.
I can wrap my head around the sidecars of dapr, but I haven't yet wrapped my head around how the current Aspire runtime feeds in values like my database connection string to the application, such that I could mimic it in a bare CLI environment.

---

Some small bits of clarity peeking through occasionally here though. The experience is still good overall and I'm enjoying it immensely.

[davidfowl]

I guess I'm just wondering why it has to be framed as a "tradeoff" at all? If someone chooses to use Aspire and dapr together, but both risk have overlapping functionality, the "opt-in" (dapr in this case) should be allowed to drive. Without creating ambiguity. Let's take the next point as an example here...

This is part of understanding what the technology does and how it works. From this discussion it sounds like you expect or want things to work a certain way. Instead, I would shift understand how the underlying tech works and use that as a basis for how the integration works.

Yeah, so in my applications, I can work with ActivitySource. Aspire - helpfully - wires all that up and captures it. But does that flow through the dapr sidecar, or does it go directly to Aspire?

I'm not sure why you would assume that it goes through dapr. ActivitySource is a .NET API that pushes traces to an activity listener. ServiceDefaults wires up an OTLP exporter which internally hooks up an activity listener and pushes traces over otlp. The aspire dashboard acts as an OTLP server so traces, logs and metrics are sent to it.

https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/dashboard/overview?tabs=bash#architecture

Another one is .WithReference, where Aspire is setting up visibility between containers, but when I'm using dapr, I don't need to worry as much about that because I'm able to use bindings. But I could easily see people mistakenly thinking that on top of configuring dapr, they also have to "mirror" that in Aspire.

WithReference doesn't change how it works because of Dapr, if it did it would be documented as such. I think the problem is jumping to conclusions or making assumptions about how things behave based on a hunch. The APIs behaviors are documented (or should be).

To a newcomer - or at least me - these can certainly be resolved individually. But it's time consuming to understand which parts are cooperating and which are - as you are saying, completely separate.

There's no shortcut for understanding technology. I do think we need to spend more time documenting how things work so that I can just point to multiple documentation links vs explaining it 😄

[davidfowl]

I forgot to mention, Aspire at its core does not need to or want to depend on dapr for any core functionality. It's an app developers' decision to use, just like our other integrations.

[atrauzzi]

From this discussion it sounds like you expect or want things to work a certain way.

Mm, not true. I would try to focus less assuming I don't grasp things, and try to take the perspective that I'm trying to avoid stubbing my toes. I'm a minimalist at heart and so what I'm looking for is the bare minimum configuration required.

I think the problem is jumping to conclusions or making assumptions about how things behave based on a hunch.

Again, I was already able to work this out for myself (ctrl-f, "orthogonal", it was literally my first sentence in this thread, yeah?), be kind,
🙏 please 🙏 . I'm just calling out the risks of how many wires there are to get crossed in working with both dapr and Aspire in conjunction with one another.

I'll keep making notes and coming up with questions as I continue to push forward. You've answered lots already, thank you.

...more time documenting how things work so that I can just point to multiple documentation links vs explaining it

A noble goal, but documentation will only get you so far. People will however find this conversation in search history over time and benefit from it. Maybe even more than any docs you could spend hours trying to perfect! 💪

Aspire at its core does not need to or want to depend on dapr for any core functionality.

I'm not saying Aspire has to integrate with dapr out of the box for core functionality. There's nothing to read between the lines here, I'm just having a normal dialogue 🙂 .

I promise, I'm here with like truckload of enthusiasm, both Aspire and dapr are so cool.

[davidfowl]

Mm, not true. I would try to focus less assuming I don't grasp things, and try to take the perspective that I'm trying to avoid stubbing my toes. I'm a minimalist at heart and so what I'm looking for is the bare minimum configuration required.

My bad. A Part of the problem is missing docs. Not just the docs we have but architecture docs for how it hangs together.

Again, I was already able to work this out for myself (ctrl-f, "orthogonal", it was literally my first sentence in this thread, yeah?), be kind,
🙏 please 🙏 . I'm just calling out the risks of how many wires there are to get crossed in working with both dapr and Aspire in conjunction with one another.

Again, sorry for myself jumping to conclusions 😊. You assume right that dapr and aspire are completely orthogonal by we want them to be complementary. We want them to work well together.

I know docs will not be enough for architecture docs will help answer the "how stuff works" vs "how should/can this stuff be combined to build my app". I hope the former will lead to a better understanding for the latter.