Components

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 repo is where you can contribute implementations for the component interfaces and extends 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 current hosting environment using the dapr components CLI command.

The following are the component types provided by Dapr:

• Bindings
• Pub/sub
• Middleware
• Service discovery name resolution
• Secret stores
• State
• Tracing exporters

Service invocation and service discovery components

Service discovery components are used with the service invocation building block to integrate with the hosting environment to provide service-to-service discovery. For example, the Kubernetes service discovery component integrates with the Kubernetes DNS service and self hosted uses mDNS.

Service invocation and middleware components

Dapr allows custom middleware to be plugged into the request processing pipeline. Middleware can perform additional actions on a request, such as authentication, encryption and message transformation before the request is routed to the user code, or before the request is returned to the client. The middleware components are used with the service invocation building block.

Secret store components

In Dapr, a secret is any piece of private information that you want to guard against unwanted users. Secrets stores, used to store secrets, are Dapr components and can be used by any of the building blocks.