Dapr uses a modular design where functionality is delivered as a component. Each component has an interface definition. All of the components are pluggable so that you can swap out one component with the same interface for another. The components contrib repository is where you can contribute implementations for the component interfaces and extend Dapr’s capabilities.
A building block can use any combination of components. For example the actors building block and the state management building block 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.
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/local folder within your solution, or globally in the
.dapr folder created when invoking
dapr 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.
Available component types
The following are the component types provided by Dapr:
State store components are data stores (databases, files, memory) that store key-value pairs as part of the state management building block.
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 broker components are message brokers that can pass messages to/from services as part of the publish & subscribe building block.
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.
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 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.
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 before the response is returned to the client. The middleware components are used with the service invocation building block.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.