Dapr

Dapr is the runtime layer between Component code and infrastructure. Every Component runs next to a Dapr sidecar and talks only to that sidecar, so the code names what it needs (a Topic, a Port, a Service) and never learns which broker, endpoint, or credential the name resolves to. Each environment decides what the names resolve to, in Dapr component configuration rendered at deploy time.

Dapr separates infrastructure choices from Component code. That separation buys flexibility in both directions: an environment can swap the broker or the endpoint behind a name in configuration, without a rebuild, and development can run on lightweight infrastructure before the production equivalents exist. In the quick start the Topic resolves to a Redis container the host starts and Ports resolve to folders, so the pipeline logic is proven before any production broker is chosen.

The sidecar

A Component and its Dapr sidecar deploy as one unit. The Component calls its sidecar over a local API, and the sidecar reads the environment’s Dapr components to decide where each call goes.

FIG DP1The Component publishes to a Topic name; each environment's Dapr component decides which broker the name resolves to.

Your code External touchpoint Infrastructure, not your code

The three environments in the figure are the ones these docs use: the quick start backs the Topic with Redis, the local cluster path with a RabbitMQ fixture, and production with whatever broker the environment owns.

Ports and adapters

A Port is the interface: the Component’s edge names where data enters or leaves. The adapter is the concrete implementation bound to that Port at deploy time. On Dapr the adapter is a binding, which supplies the protocol, the address, and the credentials..

FIG DP2The Component writes to a Port name; the environment's Dapr binding decides the adapter behind it.

Which binding a Port resolves to is chosen when manifests are rendered for an environment.

Local cluster shows the rendered Dapr component YAML for the drop-folder binding.

The runtime side of this page is Runtime concepts: how the topology becomes workloads and sidecar annotations, and the full Topic, Port, and Service mapping.