docs-aspire
docs-aspire copied to clipboard
[New article]: Aspire Dapr integration
Proposed topic or title
Dapr integration
Location in table of contents.
No response
Reason for the article
Dapr and Aspire can work together, but there is a lot of overlap as well. Why would you combine these? Where does one end and the other begin? Where do they complement, or fight each other?
Article abstract
Dapr and Aspire can work together, but there is a lot of overlap as well. Why would you combine these? Where does one end and the other begin? Where do they complement, or fight each other?
Relevant searches
No response
I love it, and I believe that answering these sorts of questions would be great! Do you want to draft up a PR, and we can go from there?
I would be up for starting a draft and helping write this, but I would need to know how Microsoft is looking at this in order to align the documentation with the direction the Dapr - Aspire integration is going
Of course, let's tag a few key stakeholders and get their perspective on how to position this. @davidfowl @DamianEdwards @mitchdenny @eerhardt and @ReubenBond.
Also tagging @hhunter-ms
I have a couple thoughts and ideas with a tutorial for dapr and aspire. I am open to critique or feedback, but I do have a few thoughts about how to explain it based off some usage of it.
-
An aspire dapr tutorial should require some baseline knowledge or understanding of dapr for the end user. It shouldn't require any in depth or deep knowledge, but in order to use aspire with dapr, you do have to have some background with it. So, the question is how to leverage the dapr documentation to reduce the amount of work needed in the aspire documentation.
-
You also have to remember that dapr automatically creates a redis and zipkin container for you, so if you try and create a redis container using host port 6379, then you will run into some error
-
Then explain the syntax sugar that adddaprstatestore and adddaprpubsub bring. And explain that the backends for the built in state store and pub sub components are in memory and don't have a backend.
-
Then show how to leverage an existing component yaml file (adddaprcomponent)
-
Then show how aspire handles orchestrating the apps resources, the dapr sidecar (from AddDaprSidecar), and the usage of the components using the resource withreference method
-
Then I think a simple example of an app host program.cs file should be shown (local development only simple). But then at the end consider how you could use the concept of a publishing context to use a different backend for a dapr component. I mean you can really do some cool stuff. For example I could leverage a bicep file that creates some azure resource for a production environment and also use some local and or in memory backend for the same component and leverage the same api with the new publish context api from preview 4.
Obviously, the first priority is the simplest use case, but I do think some thought around how to leverage existing documentation and what level of knowledge is expected in order to leverage aspire for a dapr workflow should be considered...
@IEvangelist @NicoVermeir just wanted to fully endorse having a Dapr article for Aspire. I was working on some READMEs today for the various packages in Aspire and realized we didn't have one to point to. Thanks for filing this @NicoVermeir!
/cc @philliphoff maybe you and @NicoVermeir could collaborate on this?
Would love to, but my time is very limited at the moment.
@NicoVermeir I'm happy to work with you on writing Dapr/Aspire docs. I'm a docs maintainer for Dapr open source and write Dapr articles throughout Azure documentation, so I can provide that perspective.
@hhunter-ms great! should we connect offline and get a head start? Or wait for someone from the Aspire team?
Hi @hhunter-ms and @NicoVermeir - let's schedule a meeting to get a game plan in place, with the goal of getting something stood up for //build (May 21st, 2024), if at all possible. If we're unable to get together, here are some thoughts:
-
I was imagining that this should sit under the newly added Frameworks top-level TOC, beside Orleans.
-
Other than that, I'd like to ask that we include a working project for our build system to be able to verify. Have a look at what the Orleans sample has done, placed in the snippets/Orleans directory.
└─📂 frameworks ├─📂 snippets │ └─📂 Orleans │ ├─📂 OrleansAppHost │ │ ├─📂 Properties │ │ │ └─ launchSettings.json │ │ ├─ appsettings.json │ │ ├─ aspire-manifest.json │ │ ├─ OrleansAppHost.csproj │ │ ├─ Program.cs │ │ └─ storage.module.bicep │ ├─📂 OrleansClient │ │ ├─📂 Properties │ │ │ └─ launchSettings.json │ │ ├─📂 wwwroot │ │ │ └─ index.html │ │ ├─ appsettings.json │ │ ├─ OrleansClient.csproj │ │ └─ Program.cs │ ├─📂 OrleansContracts │ │ ├─ ICounterGrain.cs │ │ └─ OrleansContracts.csproj │ ├─📂 OrleansServer │ │ ├─📂 Properties │ │ │ └─ launchSettings.json │ │ ├─ appsettings.json │ │ ├─ OrleansServer.csproj │ │ └─ Program.cs │ ├─📂 OrleansServiceDefaults │ │ ├─ Extensions.cs │ │ └─ OrleansServiceDefaults.csproj │ └─ OrleansClientServer.sln └─ orleans.md
-
Feel free to link out to additional resources as much as required and tag me for review.
@IEvangelist @NicoVermeir - I think a meeting would be good, just to get everyone on the same page. Especially with //build as a timeline.
let's do it, I'm in Belgium so UTC +2 timezone. If this is easier over email: [email protected]