Components
Dapr uses a modular design where functionality is delivered as a component. Each component has an interface definition. All of the components are interchangeable so that you can swap out one component with the same interface for another.
You can contribute implementations and extend Dapr’s component interfaces capabilities via:
A building block can use any combination of components. For example, the actors and the state management building blocks both use state components.
As another example, the pub/sub building block uses pub/sub components.
You can get a list of current components available in the hosting environment using the dapr components CLI command.
Note
For any component that returns data to the app, it is recommended to set the memory capacity of the Dapr sidecar accordingly (process or container) to avoid potential OOM panics. For example in Docker use the--memory option. For Kubernetes, use the dapr.io/sidecar-memory-limit annotation. For processes this depends on the OS and/or process orchestration tools.*Component specification
Each component has a specification (or spec) that it conforms to. Components are configured at design-time with a YAML file which is stored in either:
- A
components/localfolder within your solution, or - Globally in the
.daprfolder created when invokingdapr init.
These YAML files adhere to the generic Dapr component schema, but each is specific to the component specification.
It is important to understand that the component spec values, particularly the spec metadata, can change between components of the same component type, for example between different state stores, and that some design-time spec values can be overridden at runtime when making requests to a component’s API. As a result, it is strongly recommended to review a component’s specs, paying particular attention to the sample payloads for requests to set the metadata used to interact with the component.
Tip
For local development, the Dapr Dev Dashboard has a component builder that guides you through creating a component YAML file for any component type, so you don’t have to write the spec by hand. The dashboard also shows which components each running app has loaded, which helps to confirm that Dapr picked up your component files.The diagram below shows some examples of the components for each component type
Built-in and pluggable components
Dapr has built-in components that are included as part of the runtime. These are public components that are developed and donated by the community and are available to use in every release.
Dapr also allows for users to create their own private components called pluggable components. These are components that are self-hosted (process or container), do not need to be written in Go, exist outside the Dapr runtime, and are able to “plug” into Dapr to utilize the building block APIs.
Where possible, donating built-in components to the Dapr project and community is encouraged.
However, pluggable components are ideal for scenarios where you want to create your own private components that are not included into the Dapr project. For example:
- Your component may be specific to your company or pose IP concerns, so it cannot be included in the Dapr component repo.
- You want decouple your component updates from the Dapr release cycle.
For more information read Pluggable components overview
Hot Reloading
Since Dapr v1.18, components are “hot reloaded” at runtime by default. To opt out, disable the HotReload feature in the Dapr application configuration.
This means that you can update component configuration without restarting the Dapr runtime.
Component reloading occurs when a component resource is created, updated, or deleted, either in the Kubernetes API or in self-hosted mode when a file is changed in the resources directory.
When a component is updated, the component is first closed, and then reinitialized using the new configuration.
The component is unavailable for a short period of time during reload and reinitialization.
Hot reloading also extends to Configuration, Resiliency, and HTTPEndpoint resources. Changes to these resource types trigger a graceful restart of the Dapr sidecar (via SIGHUP) to apply the new configuration. SIGHUP is not supported on Windows. See Updating resources for more details.
Available component types
The following are the component types provided by Dapr:
Name resolution
Name resolution components are used with the service invocation building block to integrate with the hosting environment and provide service-to-service discovery. For example, the Kubernetes name resolution component integrates with the Kubernetes DNS service, self-hosted uses mDNS and clusters of VMs can use the Consul name resolution component.
Pub/sub brokers
Pub/sub broker components are message brokers that can pass messages to/from services as part of the publish & subscribe building block.
State stores
State store components are data stores (databases, files, memory) that store key-value pairs as part of the state management building block.
Bindings
External resources can connect to Dapr in order to trigger a method on an application or be called from an application as part of the bindings building block.
Secret stores
A secret is any piece of private information that you want to guard against unwanted access. Secrets stores are used to store secrets that can be retrieved and used in applications.
Configuration stores
Configuration stores are used to save application data, which can then be read by application instances on startup or notified of when changes occur. This allows for dynamic configuration.
Locks
Lock components are used as a distributed lock to provide mutually exclusive access to a resource such as a queue or database.
Cryptography
Cryptography components are used to perform cryptographic operations, including encrypting and decrypting messages, without exposing keys to your application.
Conversation
Dapr provides developers a way to abstract interactions with large language models (LLMs) with built-in security and reliability features. Use conversation components to send prompts to different LLMs, along with the conversation context.
Search
Search components are used to index, retrieve, and query documents in full-text search engines.
Vector
Vector components are used to store pre-embedded vectors and run similarity queries against vector databases.
Middleware
Dapr allows custom middleware to be plugged into the HTTP request processing pipeline. Middleware can perform additional actions on an HTTP request (such as authentication, encryption, and message transformation) before the request is routed to the user code, or the response is returned to the client. The middleware components are used with the service invocation building block.