Part 4 · 1 chapters · ~8 min

Dapr: Building Blocks as a Sidecar

The Dapr runtime as an application-level sidecar, service invocation, state management, pub/sub with CloudEvents, bindings, secrets, workflows and actors, pluggable components per environment, and when Dapr helps or hides too much.

8

Building blocks over localhost

code
# publish an event without a Kafka SDK
curl -X POST http://localhost:3500/v1.0/publish/pubsub/transfer-created \
     -H 'content-type: application/json' -d '{"transferId":"t_81723","amountKobo":1500000}'

# save and read state with optimistic concurrency (ETags)
curl -X POST localhost:3500/v1.0/state/statestore -d '[{"key":"acct-7","value":{"limit":20000000},"etag":"3"}]'

# component: the same "pubsub" name backed by Kafka in production
apiVersion: dapr.io/v1alpha1
kind: Component
metadata: { name: pubsub }
spec: { type: pubsub.kafka, version: v1, metadata: [ { name: brokers, value: "kafka:9092" } ] }
DAPR BUILDING BLOCKS
an app talks to a local sidecar API; components plug in the real infrastructure
your appany language, HTTP/gRPC to localhost:3500daprd sidecarbuilding block APIsstate storeRedis, Postgres, Cosmospub/subKafka, RabbitMQ, SNSsecretsVault, AWS SMbindingsS3, cron, SMTP
swipe the figure sideways, or tap expand for full screen
1/5
the idea
Dapr is a sidecar that exposes application-level building blocks (state, pub/sub, service invocation, bindings, secrets, workflows, actors) through a local HTTP or gRPC API.
application building blocks over localhostany language, same API