Dapr (Distributed Application Runtime) provides consistent APIs for recurring distributed-application concerns. Its building blocks include service invocation, state management, publish and subscribe, secrets, bindings, actors, configuration, and workflows. Developers call these APIs while platform teams configure the backing components. This separates application code from infrastructure-specific clients and lets teams change implementations without changing that code. section 7.3.1 section 7.0
On Kubernetes, install the Dapr control plane, then annotate an application deployment with `dapr.io/enabled: "true"` and an app ID such as `dapr.io/appid: "service-a"`. Dapr injects a `daprd` sidecar into the application’s pod. The application sends HTTP or gRPC requests to the sidecar on localhost; the sidecar uses configured Dapr components to reach the backing infrastructure. Dapr can also run outside Kubernetes. section 7.3.2 section 7.3.1
Listing 7.1 Dapr Statestore component definition
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
spec:
type: state.redis #1
version: v1
metadata:
- name: keyPrefix
value: name
- name: redisHost #2
value: redis-master:6379
- name: redisPassword #3
secretKeyRef:
name: redis
key: redis-password
auth:
secretStore: kubernetes
A Kubernetes `Component` named `statestore` selects Redis, sets its host, and obtains its password through the Kubernetes secret store. This configuration supplies the backing implementation for the state API; application code need not select Redis. section 7.3.2
Read and write state
With a component named `statestore`, POST JSON such as `[{"key":"name","value":"Bruce Wayne"}]` to `http://localhost:3500/v1.0/state/statestore`. GET `http://localhost:3500/v1.0/state/statestore/name` to read it. Port 3500 is the default Dapr HTTP port. Applications can make these requests with ordinary HTTP or gRPC facilities, or use an optional Dapr SDK rather than constructing requests manually. section 7.3.3
In a Conference application, the Agenda service can use Dapr state APIs instead of a Redis client. Services can publish events through a PubSub component instead of Kafka clients, while a subscription maps a topic to a receiving service’s route. Service invocation also permits resiliency policies without adding a service-specific library. Adoption need not be all-or-nothing: a service that needs SQL and PostgreSQL features can keep its direct PostgreSQL dependency. section 7.3.5
The practical division of work is stable application-facing APIs and environment-specific platform configuration. Platform teams can wire up different infrastructure across environments, while developers keep the same calls. The abstraction reduces routine dependency work, but component behavior still matters when designing services. section 7.4 section 7.3.5
