Building a .NET distributed application with DAPR and Azure Container Apps

DAPR is an abbreviation for Distributed APplication Runtime. As the name implies, it’s useful for container-based, distributed architectures. It makes life easier when it comes to:

• Service Discovery. When you deploy multiple instances of your application, then how do you find them? This is where DAPR comes to the rescue.
• It makes your app cloud-agnostic. That’s very convenient if, for example, you use Azure ServiceBus in production but want to use RabbitMQ locally.
• It’s a language-agnostic solution. So you can write parts of your application in Go, others in C#, others in Java, and others in Node.js.

How does it work?

DAPR works with so-called “sidecars”. For each service you have, you need to run a DAPR sidecar beside it. They will locate and communicate with other DAPR sidecars in the network.

A DAPR sidecar has a Rest-API and a gRPC API. Your application invokes them. They relay the requests to wherever they need to go. To invoke the sidecar’s APIs, there’s a DAPR NuGet Package you can install.

This is what a DAPR landscape might look like:

Figure 1: DAPR and the sidecar pattern

Service-to-service communication with DAPR and .NET: