remove duplicate section

Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
This commit is contained in:
Hannah Hunter 2024-05-08 15:47:15 -04:00
parent 2216756b8a
commit e130697262
1 changed files with 0 additions and 11 deletions

View File

@ -26,17 +26,6 @@ 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.