Software Engineer

11 minute read

13 min read 2704 words

If you’re new to microservices, you’ll soon hear terms like “Sidecar Pattern” and “Dapr”. They might sound like complex tech-talk, but they’re actually simple and very powerful tools that solve real-world problems.

In this post, we’ll break down exactly what they are, why they are important, and how they help your project.

1. The Problem: Microservices are Hard!

When you start building microservices, you realize your app needs to do more than just “business logic” (like processing an order). It also needs to:

  1. Talk to other apps (and handle when they are down).
  2. Save data to a database (and handle different database types).
  3. Send messages between apps (using queues like RabbitMQ or Kafka).
  4. Keep secrets (like API keys) safe.

Normally, you’d have to write a lot of “boilerplate” code for each of these. Even worse, if you want to switch from a SQL database to a NoSQL one, you’d have to rewrite half your app!

2. What is the Sidecar Pattern? (The “Personal Assistant”)

Imagine a motorcycle with a sidecar.

  • The motorcycle is your core application. It provides the engine and does the main work.
  • The sidecar is a separate process that runs right next to it. It’s like a personal assistant that handles all the “annoying” tasks like carrying luggage, checking the GPS, or answering phone calls.

In software, a Sidecar is a helper process. Your app focuses on the business logic, while the sidecar handles the infrastructure (like talking to databases or other services).

3. Introducing Dapr: The “Universal Adapter”

Dapr stands for Distributed Application Runtime. It is a tool that implements the Sidecar pattern.

Here’s a breakdown of the name:

  • Distributed: It is built for systems that run on multiple machines or containers (like microservices).
  • Application: It focuses on helping you build your business apps.
  • Runtime: It is a process that runs alongside your code, providing the features it needs to work.

Think of Dapr as a Universal Power Adapter.

If you travel the world, every country has different power sockets. Instead of carrying 20 different chargers, you carry one Universal Adapter.

  • Your phone (Your App) plugs into the Adapter (Dapr).
  • The Adapter (Dapr) plugs into the wall (The Database, The Message Queue, etc.).

Dapr provides “Building Blocks” for your app. Instead of learning how to talk to Redis, SQL Server, or AWS S3, you just learn how to talk to Dapr. Dapr handles the rest.

How it looks:

+-----------------------+          +-----------------------+
|  Your Application     | <------> |     Dapr Sidecar      |
|  (Python, .NET, Go)   |   HTTP   |  (Service Invocation, |
|                       |  /gRPC   |   State, Secrets)     |
+-----------------------+          +-----------+-----------+
                                               |
         (The App only                         | (Dapr talks to
          talks to Dapr)                       |  external services)
                                               v
                                     +-------------------+
                                     | External Services |
                                     | (Redis, RabbitMQ, |
                                     |  Azure CosmosDB)  |
                                     +-------------------+

4. Why is Dapr Important?

  1. You write less code: You don’t need to install 10 different database clients or learn complex SDKs for every service you use.
  2. Portability (No “Vendor Lock-in”): You can write your app locally using Redis, then deploy it to the cloud using AWS DynamoDB. You don’t have to change a single line of your code! Just change the Dapr configuration.
  3. Language Neutral: Dapr works with any language (C#, Java, Python, Go, Node.js) because it uses standard HTTP/gRPC calls.
  4. Built-in “Superpowers”: Dapr automatically handles retries, encryption between services, and collects logs for you.

5. Before Dapr vs. With Dapr

Let’s look at how Dapr simplifies your code.

Before Dapr:

To save data, you have to:

  1. Install a database client (e.g., Redis SDK).
  2. Write code to connect to the database (using connection strings).
  3. Write database-specific code to save data.
  4. If you change the database later, you must rewrite your code.
// Before Dapr: Code depends on Redis!
var redis = ConnectionMultiplexer.Connect("localhost");
var db = redis.GetDatabase();
await db.StringSetAsync("cart-1", "{ 'item': 'Laptop' }");

With Dapr:

To save data, you just make a generic call to Dapr. Dapr handles the database connection for you.

  1. Make a call to Dapr: “Hey Dapr, save this to ‘my-store’.”
  2. If you change the database later, you don’t touch your code. You only change a small configuration file (YAML).
// With Dapr: Code only depends on Dapr!
await daprClient.SaveStateAsync("my-store", "cart-1", cartItem);

6. Simple Example: State Management

Let’s say you want to save a user’s shopping cart. Normally, you’d need to install a database client, handle connection strings, and write database-specific code. With Dapr, you just make an HTTP call.

Option A: Using HTTP (Any Language)

Your app can save data by sending a POST request to the Dapr sidecar (usually running on port 3500):

POST http://localhost:3500/v1.0/state/my-store
Content-Type: application/json

[
  {
    "key": "cart-1",
    "value": { "item": "Laptop", "quantity": 1 }
  }
]

Option B: Using .NET 10

If you are using .NET, Dapr has an SDK that makes this even easier:

using Dapr.Client;

// 1. Create a Dapr Client
var client = new DaprClientBuilder().Build();

// 2. Define your data
var cartItem = new { Item = "Laptop", Quantity = 1 };

// 3. Save it via the Dapr Sidecar
await client.SaveStateAsync("my-store", "cart-1", cartItem);

Console.WriteLine("Saved to state store!");

// 4. Retrieve it later
var savedItem = await client.GetStateAsync<dynamic>("my-store", "cart-1");
Console.WriteLine($"Retrieved: {savedItem}");

Dapr handles the connection to the actual database (like Redis) based on a simple YAML configuration file. If you want to switch from Redis to SQL Server later, you don’t have to change your code—just change the Dapr config!

7. Simple Example: Service Invocation (App-to-App)

Imagine you have two microservices: OrderApp and InventoryApp. OrderApp needs to ask InventoryApp if an item is in stock.

The Old Way (Without Dapr):

OrderApp needs to know:

  • The exact IP address or URL of InventoryApp.
  • How to handle retries if InventoryApp is slow.
  • How to encrypt the communication.

The Dapr Way:

OrderApp simply tells its own Dapr sidecar: “Hey Dapr, call the ‘check-stock’ method on ‘InventoryApp’.”

Your App (OrderApp) calls its local sidecar: POST http://localhost:3500/v1.0/invoke/InventoryApp/method/check-stock

Note: 3500 is the port of the Dapr Sidecar running right next to your app.

Dapr handles the rest:

  1. Service Discovery: Dapr automatically finds where InventoryApp is running.
  2. Security: Dapr secures the connection between the two apps automatically.
  3. Retries: If InventoryApp is momentarily busy, Dapr will automatically try the call again.

8. What is a Service Mesh? (The Logistics Network)

You might hear people say that Dapr is a “Service Mesh.” That sounds fancy, but the idea is simple.

Imagine a large city with many businesses (Microservices).

  • If every business has to hire its own fleet of trucks, drivers, and security to send packages to other businesses, it’s a chaotic mess.
  • A Service Mesh is like a city-wide Integrated Logistics & Security System.

How it works with the Sidecar:

  1. Every business (Your App) gets a dedicated delivery person (The Sidecar).
  2. When Business A wants to send a package to Business B, they don’t drive there. They just give it to their Sidecar.
  3. All the Sidecars in the city talk to each other to find the best route, ensure the package isn’t stolen (Encryption), and try again if there’s a traffic jam (Retries).

The “Mesh” is simply the network formed by all these sidecars talking to each other.

Is Dapr a Service Mesh?

Yes and No.

  • Yes: Dapr handles service-to-service communication (the “Mesh” part) just like tools like Istio or Linkerd.
  • No (It’s more!): Traditional service meshes only focus on the network (routing, security). Dapr also provides Application Building Blocks (saving data to a database, sending messages to a queue, managing secrets).

Summary: A Service Mesh is the “web” of sidecars that manage how your services talk to each other. Dapr gives you this web, plus a lot of other tools to build your app faster.

9. Dapr Components: The “Magic” Configuration

You might wonder: “How does Dapr know which database to use if I don’t put it in my code?”

The answer is Dapr Components. These are simple YAML files that tell Dapr what to plug into.

Example: my-store.yaml

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: my-store # This is the name you use in your code!
spec:
  type: state.redis # This tells Dapr to use Redis
  metadata:
  - name: redisHost
    value: localhost:6379

To switch to a different database, you just change the type and metadata in this YAML file. Your application code remains exactly the same!

10. Concrete Example: How Dapr acts as your “SQL Messenger”

You asked a great question: “If I need to delete a record with a foreign key in SQL Server, how do I use Dapr? Do I still need a Repository and Interface?”

To understand this, think of Dapr as a Messenger Service.

In the old way (Traditional Architecture), you had to build a whole “Post Office” (Repository, Interface, Connection Pooling, Entity Framework) inside your app just to send one message to the database.

With Dapr, you just hand the message to the sidecar.

The “Concrete” Workflow:

Let’s say you want to delete a User who has many Orders (the Foreign Key relationship).

Step 1: Tell Dapr where the Database is (The Component)

You create a small YAML file. This is the only place where you put your connection string. Your C# code never sees it!

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: shop-db # The name we use in our code
spec:
  type: bindings.sqlserver
  metadata:
  - name: connectionString
    value: "Server=tcp:myserver.database.windows.net;Database=ShopDB;..."

Step 2: Send the Command from your Code

Instead of writing a complex Repository layer, your Controller just sends the SQL command directly to the Dapr Sidecar.

// Inside your Controller (e.g., UserController.cs)
[HttpDelete("{id}")]
public async Task<IActionResult> DeleteUser(int id)
{
    // 1. The SQL Command 
    // (Note: If your DB is set to 'Cascade Delete', it handles the Foreign Keys automatically!)
    var sql = "DELETE FROM Users WHERE UserId = @id";
    
    // 2. The parameters
    var metadata = new Dictionary<string, string> { { "id", id.ToString() } };

    // 3. Hand the command to Dapr!
    // We tell Dapr: "Hey, use 'shop-db' to 'execute' this 'sql' for me."
    await daprClient.InvokeBindingAsync("shop-db", "exec", sql, metadata);

    return Ok("User deleted successfully!");
}

Does this mean you don’t need a Repository?

Mostly, yes!

  • Before Dapr: You needed: Controller -> Interface -> Repository -> Entity Framework -> SQL Server.
  • With Dapr: You only need: Controller -> Dapr Sidecar -> SQL Server.

Dapr acts as your Data Access Layer. You still need the Controller to receive the web request, but the “plumbing” code (the Repository) is gone because the Dapr Sidecar handles it for you.

11. Do I need Docker or Kubernetes to use Dapr?

You’ve probably heard Dapr mentioned with Docker and Kubernetes, but you don’t actually need them to start learning or building with Dapr!

1. Self-Hosted Mode (Local Development)

When you’re building on your own computer, you can run Dapr in Self-Hosted Mode.

  • You don’t need a complex server cluster (Kubernetes).
  • You can run Dapr as a simple process (like a console app) on your machine.
  • Your .NET app just talks to the Dapr Sidecar process on its local port.

2. What about the SDK?

The .NET SDK isn’t Dapr itself; it’s a Client.

  • Think of it like a Remote Control.
  • The Dapr Sidecar is the Television.
  • You can’t use the remote (SDK) to watch TV if the TV (Sidecar) isn’t turned on!
  • You must have the Dapr Sidecar running on your machine for the SDK to work.

3. What about Docker?

By default, when you install Dapr locally, it uses Docker Desktop to run two helper services: Redis (for your database) and Zipkin (for logs).

  • If you have Docker: Dapr is super easy to set up with one command (dapr init).
  • If you don’t want to use Docker: You can still use Dapr! You’ll just have to manually run your own database and tell Dapr where it is.

Summary: For a beginner, it’s best to have Docker Desktop installed so Dapr can handle the “plumbing” for you, but you definitely don’t need Kubernetes yet.

12. How it helps your project

If you are building a modern project, Dapr helps you by:

  • Speeding up development: You focus on the features, not the plumbing.
  • Improving reliability: Dapr automatically handles things like connection retries and timeouts.
  • Standardizing security: All communication between your microservices is encrypted automatically by Dapr.
  • Ease of testing: You can swap out a heavy cloud database for a lightweight local one during development without touching your app’s code.

13. Key Takeaways

  1. The Sidecar Pattern is like a personal assistant for your app.
  2. Dapr is the Universal Adapter that lets your app talk to any database, queue, or service using a simple standard.
  3. Separation of Concerns: Your code handles the “What” (Save data, Call app), and Dapr handles the “How” (Redis, SQL, Retries, Security).
  4. No Code Changes: You can swap your database or message queue by changing a YAML file, not your application code.
  5. Less Boilerplate: You don’t need heavy database libraries or complex repository layers; Dapr acts as your data access layer.
  6. Infrastructure Flexibility: You can run Dapr locally without Kubernetes and even without Docker if needed.
  7. Service Mesh: Dapr automatically manages the “web” of communication between your services, including discovery and security.

The Sidecar pattern is a must-know for modern cloud-native developers. By using Dapr, you can build distributed systems faster and with less boilerplate code.

14. Further Reading & References

If you’re excited about Dapr and want to dive deeper, check out these excellent resources:

Leave a comment

You may also enjoy