Dapr: Distributed Application Runtime Introduction

Dapr (Distributed Application Runtime) simplifies cloud-native development by abstracting away the complexity of distributed systems. It provides “building blocks” like Service Invocation, State Management, and Pub/Sub via a sidecar architecture. This means your code (C#, Go, Node) talks to localhost via HTTP/gRPC, and Dapr handles the infrastructure.

The Sidecar Pattern

flowchart TB
    subgraph Pod A
        AppA[Order Service] <-->|HTTP| DaprA[Dapr Sidecar]
    end
    
    subgraph Pod B
        DaprB[Dapr Sidecar] <-->|HTTP| AppB[Payment Service]
    end
    
    DaprA -->|mTLS| DaprB
    DaprA -->|State| Redis
    DaprA -->|PubSub| Kafka
    
    style DaprA fill:#E1F5FE,stroke:#0277BD
    style DaprB fill:#E1F5FE,stroke:#0277BD

Building Block: Pub/Sub

Publish a message without knowing the broker (Redis, Service Bus, RabbitMQ).

// Publisher
var client = new DaprClientBuilder().Build();
await client.PublishEventAsync("pubsub", "orders", new Order { Id = 123 });

// Subscriber (ASP.NET Core)
[Topic("pubsub", "orders")]
[HttpPost("orders")]
public IActionResult ProcessOrder([FromBody] Order order)
{
    // ...
    return Ok();
}

Building Block: State Management

// Save State
await client.SaveStateAsync("statestore", "order-123", order);

// Get State
var order = await client.GetStateAsync<Order>("statestore", "order-123");

Key Takeaways

• Dapr is not a Service Mesh; it focuses on application logic (State, PubSub, Bindings).
• Runs on Kubernetes as a sidecar or self-hosted process.
• Developers code against the Dapr API, not the infrastructure SDKs.