add section for types and ids

Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
Signed-off-by: salaboy <Salaboy@gmail.com>
This commit is contained in:
Hannah Hunter 2023-05-18 14:34:06 -04:00 committed by salaboy
parent f0502e896b
commit 97a1b18226
1 changed files with 11 additions and 0 deletions

View File

@ -26,6 +26,17 @@ Every actor is defined as an instance of an actor type, identical to the way an
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/0y7ne6teHT4?si=dWNgtsp61f3Sjq0n&amp;start=10797" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
## Actor types and IDs
To communicate with an actor, you need to know its actor _type_ and actor _id_.
- **Actor type** uniquely identifies the actor implementation across the whole application.
- **Actor ID** uniquely identifies an instance of that type.
If you don't have an actor `id` and want to communicate with a new instance, you can create a random ID. Since the random ID is a cryptographically strong identifier, the runtime will create a new actor instance when you interact with it.
[Learn more about how each Dapr SDK handles actor types, actor ids, and actor interfaces.]({{< ref sdks >}})
## Dapr actors vs. Dapr Workflow
Dapr actors builds on the state management and service invocation APIs to create stateful, long running objects with identity. [Dapr Workflow]({{< ref workflow-overview.md >}}) and Dapr Actors are related, with workflows building on actors to provide a higher level of abstraction to orchestrate a set of actors, implementing common workflow patterns and managing the lifecycle of actors on your behalf.