Coding With Taz

In Part 2, we got Dapr running locally and saw how the sidecar fits into a normal development workflow. Now we can start using Dapr for real work and state management is usually the first building block teams adopt.

State is one of the earliest places where infrastructure concerns leak into application code. Even simple services end up tightly coupled to a specific database client, connection logic, retry behavior, and environment‑specific configuration. Dapr’s state API is designed to remove that coupling by providing a consistent abstraction over state, regardless of the backing store.

This post walks through how Dapr handles state using Redis and Postgres, why this abstraction works well in real systems, and how to use it in both Go and .NET.

Why Traditional State Access Becomes a Problem

Most applications interact with state using vendor‑specific SDKs. That works at first, but over time it introduces friction:

Switching from Redis to Postgres requires code changes
Local development often uses a different store than production
Each service implements its own retry and error handling
Testing requires mocking database clients
Polyglot teams duplicate the same logic in multiple languages
As systems grow, these concerns multiply across services and environments

Dapr’s state building block exists to eliminate this entire class of coupling

Dapr’s State Management Model

Dapr exposes a simple key/value state API over HTTP or gRPC.

Your application:

Saves state by key
Retrieves state by key
Deletes state by key

It does not know:

Which database is being used
How connections are managed
How retries or consistency are handled
How serialization works
How secrets are stored

Those details live in a state store component, defined outside of your application code.

Architecture Overview

At runtime, state access looks like this:

Application → Dapr State API → State Store (Redis / Postgres / etc.)

Your application talks only to the local Dapr sidecar. Dapr handles communication with the configured state store.

This separation allows you to change the backing store without touching application code.

Saving and Retrieving State

From the application’s perspective, state operations are straightforward.

Typical operations include:

Saving an object under a key
Retrieving it later
Updating or deleting it

The same API works whether the backing store is Redis, Postgres, Cosmos DB, DynamoDB, or something else.

This is especially useful in polyglot environments, where different services are written in different languages but share the same state access patterns.

Configuring a Redis State Store

Before writing any application code, you define a Dapr state store component.

Redis state store component

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
spec:
  type: state.redis
  version: v1
  metadata:
    - name: redisHost
      value: localhost:6379
    - name: redisPassword
      value: ""

A few important notes:

You can restrict components to specific apps using scopes:
Secrets should be stored in a secret store component, not inline
In local mode, components load at startup (no hot‑reload)
In Kubernetes, components can be updated dynamically

Once this component is in place, any service using Dapr can access Redis state via the statestore name.

No code changes are required if you later swap Redis for Postgres

Go Example: Saving and Retrieving State

In Go, using the official Dapr SDK.

Saving state

package main

import (
	"context"
	"encoding/json"
	"fmt"

	"github.com/dapr/go-sdk/client"
)

type Order struct {
	Id string `json:"id"`
	Amount  int    `json:"amount"`
}

func main() {
	ctx := context.Background()
	daprClient, _ := client.NewClient()
	order := Order{Id: "order-123", Amount: 100}
	saveOrder(ctx, daprClient, order)

	retrievedOrder, _ := getOrder(ctx, daprClient, order.Id)

	fmt.Printf("%s - %d", retrievedOrder.Id, retrievedOrder.Amount)
}

func saveOrder(ctx context.Context, daprClient client.Client, order Order) error {
	orderData, err := json.Marshal(order)
	if err != nil {
		return err
	}
	return daprClient.SaveState(ctx, "statestore", order.Id, orderData, nil)
}

Retrieving state

func getOrder(ctx context.Context, daprClient client.Client, orderID string) (*Order, error) {
	result, err := daprClient.GetState(ctx, "statestore", orderID, nil)
	if err != nil {
		return nil, err
	}

	if result.Value == nil {
		return nil, nil // Order not found
	}

	var order Order
	if err := json.Unmarshal(result.Value, &order); err != nil {
		return nil, err
	}

	return &order, nil
}

There is no Redis client, no connection string, and no retry logic in the application code. Dapr handles all of that.

.NET Example: Saving and Retrieving State

In .NET, using the official Dapr SDK.

Saving state

using Dapr.Client;
var client = new DaprClientBuilder().Build();

var order = new Order("order-123",100);
 
await client.SaveStateAsync(
    "statestore",
    order.Id,
    order
);

public record Order(string Id, int Amount);

Retrieving state

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

Again, the application code has no knowledge of Redis, Postgres, or any other backing store.

Using Dapr Without an SDK (Optional)

You don’t need to use a language‑specific SDK to work with Dapr. Every building block is ultimately exposed through simple HTTP endpoints on the local sidecar. This is useful when:

your language doesn’t have an official SDK
you want to minimize dependencies
you’re debugging or testing behavior directly

The examples below show the same state operations using plain curl against the Dapr sidecar (default port 3500):

curl -X POST http://localhost:3500/v1.0/state/statestore \
  -H "Content-Type: application/json" \
  -d '[ { "key": "order-123", "value": { "id": "order-123", "amount": 100 } } ]'

curl http://localhost:3500/v1.0/state/statestore/order-123

These raw HTTP calls are exactly what the Go and .NET SDKs generate under the hood.

Switching to Postgres Without Code Changes

To switch from Redis to Postgres, the application code stays exactly the same. Only the component configuration changes.

Postgres state store component

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
spec:
  type: state.postgresql
  version: v1
  metadata:
    - name: connectionString
      value: "host=localhost user=postgres password=postgres dbname=dapr"

From the application’s perspective:

The API is unchanged
The state store name is unchanged
No redeploy is required beyond configuration

This is one of the most practical benefits of Dapr in real systems.

Additional Features You Should Know About

Dapr’s state API includes several capabilities that go beyond simple key/value access.

Optimistic concurrency (ETags)

Dapr supports ETags to prevent lost updates.

Transactional state operations

You can save multiple keys atomically.

Consistency modes

State stores can define:

strong consistency
eventual consistency

TTL (time‑to‑live)

Some state stores support per‑key expiration.

These features become important as systems grow.

Why This Matters in Practice

Using Dapr for state management enables:

Infrastructure portability – swap Redis for Postgres without rewriting services
Environment parity – local, staging, and production behave consistently
Simpler testing – state access can be tested via HTTP
Cleaner codebases – business logic stays separate from infrastructure concerns

This is especially valuable in polyglot or multi‑team environments.

Limitations to Keep in Mind

Dapr’s state API is intentionally simple. It works best for:

Service‑owned state
Event‑driven workflows
Key/value access patterns

It is not a replacement for:

Complex relational queries
Reporting or analytics workloads
Heavy analytical use cases

Many systems use Dapr for service state while still accessing databases directly for read‑heavy or query‑driven workloads.

What’s Next

Now that we can store and retrieve state, we can move on to one of the most powerful parts of Dapr: Publish and Subscribe.

In the next post, we’ll explore:

Publishing events without broker‑specific SDKs
Subscribing to messages using HTTP endpoints
Switching between Kafka, RabbitMQ, and Azure Service Bus via configuration

This is where Dapr really starts to shine in event‑driven systems.

In Part 1, we explored what Dapr is and why it exists. Now it’s time to make it real. Before you can use state management, pub/sub, or any other building block, you need a smooth local development workflow, one that feels natural, fast, and familiar.

Dapr is often associated with Kubernetes and cloud deployments, but most development happens on a laptop. If Dapr doesn’t fit cleanly into your inner loop, it won’t be adopted at all. This post focuses on exactly that: running and debugging Dapr locally, using the same workflow you’d expect for any other service.

What “Running Dapr Locally” Actually Means

Running Dapr locally does not mean:

Running Kubernetes
Deploying to the cloud
Learning a new development model

It means:

Running your application as a normal process
Running Dapr as a sidecar alongside it
Using local infrastructure (or containers) for dependencies

Dapr was designed for fast, iterative development and that’s what we’ll focus on here.

Installing Dapr Locally

Dapr consists of two main parts:

The Dapr CLI
The Dapr runtime

Once the CLI is installed, initialising Dapr locally is a one‑time step:

dapr init

This sets up:

The Dapr runtime
A local Redis instance (used by default for state and pub/sub)
The placement service (used only for actors)

You don’t need to understand all of these yet. The important part is: Dapr now has everything it needs to run locally.

Note: In local mode, Dapr loads components at startup and does not hot‑reload them. In Kubernetes, components can be updated dynamically.

Your First Local Dapr App

At its simplest, running an app with Dapr looks like this:

.NET example

dapr run \
  --app-id myapp \
  --app-port 8080 \
  --dapr-http-port 3500 \
  -- dotnet run

Or for Go:

Go example

dapr run \
  --app-id myapp \
  --app-port 8080 \
  --dapr-http-port 3500 \
  -- go run main.go

What’s happening here:

Your application runs exactly as it normally would
Dapr starts a sidecar process alongside it
Dapr listens on port 3500
Your app listens on its own port (e.g. 8080)

From your application’s point of view, nothing special is happening and that’s the point.

Understanding the Local Architecture

Locally, the architecture looks like this:

Your App (8080)
      ↓
Dapr Sidecar (3500)
      ↓
Local Infrastructure (Redis, etc.)

Your application:

Receives HTTP requests as usual
Calls Dapr via HTTP or gRPC when it needs state, pub/sub, or bindings

Dapr:

Handles communication with infrastructure
Manages retries, timeouts, and serialisation
Emits logs and metrics independently

This separation is key to understanding how Dapr fits into your workflow.

Adding Components Locally

Dapr integrations are configured using components, which are simple YAML files.

Locally, components are usually placed in a components/ directory:

components/
└── statestore.yaml

When you run Dapr, you point it at this directory:

dapr run \
  --app-id myapp \
  --app-port 8080 \
  --components-path ./components \
  -- dotnet run

This mirrors how Dapr is configured in production, the same components, the same structure, just running locally.

Note: If you don’t specify a components path, Dapr uses the default directory at ~/.dapr/components.

Debugging with Dapr

This is where Dapr fits surprisingly well into normal development workflows.

Debugging the application

Your application runs as a normal process:

Attach a debugger
Set breakpoints
Step through code
Inspect variables

Nothing about Dapr changes this.

Debugging Dapr itself

Dapr runs as a separate process, with its own logs.

Useful commands include:

dapr list
dapr logs --app-id myapp

This separation makes it easier to answer an important question:

“Is this a bug in my application, or a configuration/infrastructure issue?”

Common Local Pitfalls

A few things that commonly trip people up:

Port conflicts

Dapr needs its own HTTP and gRPC ports.

Forgetting to restart Dapr

Component changes require restarting the sidecar.

Confusing app logs with Dapr logs

They are separate processes, check both.

Missing components path

If Dapr can’t find your components, integrations won’t work.

Once you understand these, local development becomes predictable and fast

Why This Matters for the Rest of the Series

Everything else in this series builds on this local setup:

State management
Pub/Sub
Bindings and storage
End‑to‑end workflows

The same dapr run workflow applies everywhere. Once you’re comfortable running and debugging Dapr locally, the rest of the building blocks feel much less intimidating.

What’s Next

Now that we can run and debug Dapr locally, we can start using it for real work.

In the next post, we’ll look at State Management with Dapr, using Redis and Postgres, all running locally, using the setup described here.