Update daprdocs/content/en/operations/components/pluggable-components-registration.md

Signed-off-by: Tiago Alves Macambira <tmacam@burocrata.org>
This commit is contained in:
Tiago Alves Macambira 2023-02-10 09:41:11 -08:00 committed by GitHub
parent 8da777f8e8
commit 40ecf2894a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions

View File

@ -57,7 +57,7 @@ Since you are running Dapr in the same host as the component, verify this folder
A pluggable component accessible through a [Unix Domain Socket][UDS] can host multiple distinct component APIs . During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs.
Typically, a pluggable component implements a single component API for packaging and deployment. However, at the expense of having dependencies and security, a pluggable component can have multiple component APIs implemented to ease the deployment burden. Best practice for isolation, fault tolerance, and security is a single component API implementation for each pluggable component.
Typically, a pluggable component implements a single component API for packaging and deployment. However, at the expense of increasing its dependencies and broadening its security attack surface, a pluggable component can have multiple component APIs implemented. This could be done to ease the deployment and monitoring burden. Best practice for isolation, fault tolerance, and security is a single component API implementation for each pluggable component.
## Define the component