Explore the sidecar runtime APIs — state management, pub/sub, service invocation, and pluggable components
0 / 5 completed
1 / 5
What is Dapr (Distributed Application Runtime)?
Dapr: runs as a sidecar alongside your service and exposes language-agnostic building-block APIs — for state, pub/sub, service invocation, bindings, secrets, and more — over HTTP or gRPC. Your application calls these standard APIs instead of vendor SDKs, and Dapr handles the underlying infrastructure component.
2 / 5
How does the state management building block work?
State management: the app calls POST /v1.0/state/<store> to save and GET to retrieve, optionally with ETags for concurrency and consistency settings. The actual backing store is defined in a component YAML, so you can swap Redis for another supported store without changing application code.
3 / 5
What does the pub/sub building block abstract?
Pub/sub: publish with POST /v1.0/publish/<pubsub>/<topic> and declare subscriptions so Dapr delivers messages to your endpoint. The pub/sub component (Kafka, RabbitMQ, Azure Service Bus, etc.) is configured separately, so switching brokers needs no application code changes and supports the CloudEvents format.
4 / 5
What problem does service invocation solve in Dapr?
Service invocation: call another service via POST /v1.0/invoke/<app-id>/method/<name>. Dapr resolves the target through name resolution, applies mTLS encryption, automatic retries, and distributed tracing, and forwards the request. Your code references a logical app-id instead of a network address, simplifying service-to-service communication.
5 / 5
What are Dapr components?
Components: are YAML resources that bind a building-block API to a concrete implementation, e.g. type: state.redis or type: pubsub.kafka, with connection metadata. Because the app only talks to the abstract API, changing a component's type reconfigures the backing technology without touching application logic — the heart of Dapr's portability.