Table of Contents
As a backend developer, I’m highly aware that microservices are currently one of the most popular ways of building enterprise applications. We’ll discuss Dapr and how it can help us.
Developing with microservices is great, but also tricky.
Every time we are building something, we have to think about so many things. And if we don’t have enough experience, there are a lot of places where we are just stuck.
We have to think about multiple things. What services we are going to use, how those services are going to be implemented, how the client for each service looks like, what communication patterns are we going to use… We struggle with connections, resiliency, cloud-specific issues.
Overall, if we decide to build microservices, we spend a lot of time on the stuff that should be easy to work with, on stuff that is not interesting to the business department, to our clients. Sometimes these things are blocking us from focusing on what’s important.
This is where Dapr comes to place.
Blog Series – Dapr And Microservices
Part 1: Introduction | Part 2: Demo | Part 3: Hosting and Deployment
What is Dapr (Distributed Application Runtime)?
Dapr stands for distributed application runtime.
As its logo implies, it has noble goals, and they are pretty simple. It allows us to build applications by doing all of the hard work scoped to all the problems which I have mentioned before.
Dapr is just an awesome package of building blocks that lets us focus on what’s important in developing distributed applications. It’s something you add to your everyday life of distributed applications development. It adopts the latest standards, best practices, it’s lightweight and easy to use.
The best thing is that it’s Open Source and supports many programming languages and frameworks. It’s driven by the community, not some company that wants to earn a lot of money.
How Dapr Works
Challenges related to microservices can be divided into multiple categories. Those categories contain a lot of components.
The package is just a pretty good extension that you use to use those components.
You can talk to those components via Dapr using either HTTP or gRPC API.
You can use almost any language or framework for Dapr, and any cloud or edge infrastructure.
For example, you can use some of the components from Azure and some from AWS in one application. The best thing is that the application does not have to know that you are using Azure Storage or AWS. It takes care of that.
You put Dapr in front of every service you have in your microservice-based application, and it takes care of communication and acting with multiple components.
There are many components inside Dapr.
At the moment of writing, there are over 70 are available. For example, there are many ready components for state stores such as Azure CosmosDB, Firebase, Redis, etc.
You can contribute if you want and create new components together with other people – because this is community-driven.
Summary – Distributed Application Runtime And Microservices
We covered a pretty powerful tool that solves a lot of problems for us (developers). We don’t have to worry about how to implement for example Azure Blob File Storage connector inside our applications – we simply inject a Dapr client, and use it.
This saves a lot of time, problems, and money.
Plus, your project board won’t have a gigantic amount of bugs due to the wrong implementation – you can focus on features, and also you can be fully flexible with choosing the proper cloud provider because it does not make a difference for you.
Are you convinced yet? No? Maybe because this is mainly theory. In the next text, we include a simple example of how you can quickly discover Dapr power in the .NET Core framework.
