[adamfeldman]

I'm excited by Dapr!

If I understand it correctly, it will make it easier for me to build applications by separating the "plumbing" (stateful & handled by Dapr) from my business logic (stateless, speaks to Dapr over gRPC). If I build using event-driven patterns, my business logic can be called in response to state changes in the system as a whole.

I think an example of stateful "plumbing" is a non-functional concern such as retrying a service call or a write to a queue if the initial attempt fails. Since Dapr runs next to my application as a sidecar, it's unlikely that communication failures will occur within the local node.

There seem to be extensive, nice docs on the concepts behind Dapr: https://github.com/dapr/docs/tree/master/concepts.

[adamfeldman]

I like the idea of actors to encapsulate state management for my aggregates (a la Domain Driven Design). But I haven't wanted to be limited to just using Elixir/BEAM or an actor toolkit on the JVM.

I'd wager that Dapr's virtual actors [1] were inspired in-part by Microsoft's work on Orleans [2]. I've read through some of the Orleans docs, and Dapr looks to be a more accessible (cross-language, non-CLR!) way to build using some of Orleans' concepts and capabilities.

!! this is super cool: "You can also perform aggregate queries across actor instances, avoiding the common turn-based concurrency limitations of actor frameworks [3].

[1]: https://github.com/dapr/docs/tree/master/concepts/actor [2]: http://dotnet.github.io/orleans/ [3]: https://github.com/dapr/docs/blob/master/concepts/state-mana...

[nicocesar]

Dapr's virtual actors sounds like a good idea, but besides the API spec[1] is there any better doc to have a look to an example? How are the callbacks used..?

I want to give it a try, but really seems that is pre-alpha.

[1] https://github.com/dapr/docs/blob/master/reference/api/actor...

[yodon]

Anyone know how/if Dapr is related to Orleans or whether there is any cross pollination between the teams?