Dapr — Distributed Application Runtime for Cloud and Edge

What it is

Dapr (Distributed Application Runtime) is a portable, event-driven runtime that simplifies building resilient microservices. It provides building-block APIs for common distributed system patterns: service-to-service invocation, state management, publish/subscribe messaging, resource bindings, and observability.

Backend developers building microservice architectures who want to avoid implementing distributed system patterns from scratch will find Dapr useful. It runs as a sidecar process alongside your application and works with any language or framework.

How it saves time or tokens

Dapr abstracts infrastructure concerns behind stable HTTP/gRPC APIs. Instead of integrating directly with Redis, Kafka, or PostgreSQL for state and messaging, you call Dapr's API and configure the backend component separately. Switching from Redis to Cosmos DB requires a config change, not a code change.

How to use

1. Install the Dapr CLI and initialize Dapr on your local machine or Kubernetes cluster.
2. Define component configurations for the building blocks you need (state store, pub/sub broker, etc.).
3. Call Dapr's HTTP or gRPC APIs from your application code to use state, messaging, and service invocation.

Example

# Install Dapr CLI
curl -fsSL https://raw.githubusercontent.com/dapr/cli/master/install/install.sh | bash

# Initialize Dapr locally
dapr init

# Run an app with Dapr sidecar
dapr run --app-id myapp --app-port 3000 -- node app.js

# Save state via Dapr HTTP API
import requests

DADR_URL = 'http://localhost:3500'
requests.post(
    f'{DADR_URL}/v1.0/state/statestore',
    json=[{'key': 'user-1', 'value': {'name': 'Alice', 'score': 42}}]
)

Related on TokRepo

• AI tools for DevOps — Other runtime and infrastructure tools for distributed systems.
• AI tools for self-hosted — Self-hosted platforms for running microservices.

Common pitfalls

• Running Dapr without understanding the sidecar pattern. Each application instance gets its own Dapr sidecar; this adds a process per instance.
• Choosing components without considering production requirements. The default in-memory state store loses data on restart; configure a durable backend before deploying.
• Ignoring Dapr's port configuration. The default sidecar port (3500) must not conflict with your application's ports.