Dapr for .NET Developers is a great book, read in a weekend, to start gaining an understanding of what Dapr is and especially for .NET Developers. In this post, we will see how you can use .NET to create a service and run it with Dapr and what does this provides.
Dapr for Distributed Application Runtime is a new way to build modern distributed applications. It simplifies cloud-native application development by letting you focus on your application’s core logic and keep your code simple and portable.
Dapr helps developers build event-driven, resilient distributed applications. Whether on-premises, in the cloud, or on an edge device, Dapr helps you tackle the challenges that come with building microservices and keeps your code platform agnostic.
Dapr v1.0 announced on February 17, 2021 is now production ready.
To be able to follow this simple example you will have to
Let’s create a basic web API using a .NET template
We now have a simple web API which we can call using any web browser using the URL https://localhost:5001/weatherforecast. Nothing too special about it at the moment.
Dapr uses the sidecar pattern, so we will run our web API and expose it through a Dapr sidecar.
dapr run --app-id weatherforecastservice --dapr-http-port 3500 --app-port 5001 --app-ssl -- dotnet run
Let’s break down this command to understand it:
- –app-id gives an id to our application/service, used for service discovery, in this case weatherforecastservice
- –dapr-http-port the HTTP port for Dapr to listen on, 3500
- –app-port the port your application is listening on, 5001 is the https port of our service
- –app-ssl enables https when Dapr invokes the application
- – dotnet run is the way to run our web API
Before running our web API in dapr we could access our web API using
and it is still the case, but now we can also access it using its sidecar URL
With this last URI, we invoke the Dapr sidecar by using the native invoke API built into Dapr. In this case, we call the API with HTTP but you can also call it with gRPC. The way to call it is standardized in the following way
So, having such a standard way of calling services using the service invocation Dapr building block gives you access to built-in
- Service discovery
- Distributed tracing
- Error handling
One other great benefit is that you don’t need to care in your application code about those things as those are externalized and handled by Dapr. So, you write code like you are used to and enrich your service with Dapr.
You might have some performance concerns and you can read more about this topic on Dapr performance considerations.
We have touched only the surface of what Dapr can provide, nevertheless, we have seen how easy it is to expose your web API using Dapr and the benefits it can provide, e.g. service discovery.