Proposal: Actors Quickstart

[paulyuk]

I propose we have a new quickstart for Actors that does something cool in five mins, but also drives home some concepts of actors like: many stateful objects at once, autonomous behavior, timers and reminders, actors that can notify others, aggregates.

The theme in mind here is IoT twins for "Smart" smoke detectors. This would show off these features or concepts:

• Start with 3 SmokeDetector Actors instances at first, but shows it could trivially scale out to 1000+. We would only have 1-2 Actor types to keep things simple.
• Each SmokeDetector actor has stateful properties like status, battery, name, location, firmware version
• When a SmokeDetector actor alarms, it can notify the other actors
• A Control actor can command/control/View all actors, like initiate a test after receiving a slow signal from one, and can also view battery status (e.g. 1 of 3 low).

The quickstart will meet all the usual requirements:

• Full documentation
• Full MMD tests
• Available in Python, C#, Java, and Golang [+ Node.js when available]

SDK implementation status.

• C# .NET PR New Actors .NET Quickstart #804
• Python example
• Java
• Golang

@dapr/maintainers-dapr @greenie-msft @msfussell

@marcduiker (from Discord), I'd love to collab.

[paulyuk]

There is a related ask for an Actors "starter" and we can consider one after this feature gets some steam.

[codeputer]

May I suggest why this DAPR Actor would be used on what is now becoming a crowded field in Virtual Actors. I started with ServiceFabric (where is that now???), and a few others. I now know that NewOrleans is in .Net7, so why not use that? I know that DAPR is an abstraction layer, but I have long learned via WCF that being everything to everyone is a failing value proposition - and we got stuck with REST - no data or service contract other than HTTP verbs and a crappy serialization format called JSON. Highest level of abstraction is one that does nothing!

[yaron2]

Hi @codeputer, this issue is not the place to discuss your questions, however:

I now know that NewOrleans is in .Net7, so why not use that?

Dapr actors are available for Python, Javascript, Golang, PHP, Dotnet and Java, giving a consistent actor programming model experience to both dotnet and non-dotnet developers.

I know that DAPR is an abstraction layer,

Dapr actors are in fact not an abstraction layer, but its own programming model exposed via strongly typed SDKs.

and we got stuck with REST - no data or service contract other than HTTP verbs and a crappy serialization format called JSON. Highest level of abstraction is one that does nothing!

Users using Dapr actors do not need to deal with REST or HTTP at all. As a semi-related side note, most Dapr SDKs use gRPC under the hood.

[marcduiker]

Hi @paulyuk, please add me to the fork you're planning to create as you mentioned on Discord. I'm most comfortable with C# and JavaScript, but I should be able to figure out Java and Python as well.

[paulyuk]

Hi @marcduiker - will do - I would like to get a bit more community feedback and approvals from maintainers too before we get too far down implementation. Will keep you in loop!

[cgillum]

I wonder if there's too much going on in the smart smoke detector quickstart to where it might distract from the value prop of actors. It's also not immediately obvious to me why you'd use an actor and not an API + database for this scenario. Yes, actors give you concurrency control for free but is it really solving a critical problem in this example, is it?

I wonder if there's a simpler example that could be used. What about an actor that counts votes? The example I have in mind is that I have a voting app where users can submit votes on some topic/question, and I deploy an actor that keeps a running tally. A web frontend can periodically query the actor state to get the current tally. Concurrency in cases like this makes a huge difference, which helps readers understand why they should consider actors. The example is also something that anyone can understand (you don't need to know anything about smart devices or IoT).

Thoughts?

[msfussell]

I have the same feedback as Chris, that we should keep this understandable. Can we simplify the IoT scenario?

1. Have 3 IoT devices at most.
2. Have an aggregate "View/Control" actor which gathers the information from each of the three devices to show an aggregate view of the devices and can be used to send updates to each of the device actors. This shows that Actor to actor communication

[paulyuk]

Updated to simplify based on feedback from @cgillum and @msfussell .

I still prefer this device example over voting, because I would still imagine voting being better handled or handled well by plain old HTTP or pubsub.

[msfussell]

@paulyuk - Approved

[paulyuk]

Hey @marcduiker I created this fork/branch and added you as a collaborator.
https://github.com/paulyuk/quickstarts/tree/feature/actors

[paulyuk]

New feature merged with #804. Done!