Fair warning: I haven't specifically used dapr, but I have had a look at their docs and used similar tools in the past.
Deploying apps easily to "modern clouds" and taking advantage of their feature set requires some design decisions in your app. Generally, the biggest goal here is to be able to easily scale just by spinning up more copies, so your app needs to be able to run multiple copies in parallel serving requests without exploding. We call these types of applications "cloud native".
Additionally, if you go with a microservices style architecture (I'm not going to go into the pros and cons here), there's extra concerns with communication across the different services and similar.
Often, you'll end up reinventing the wheel and writing a ton of boilerplate to cleanly solve these issues. Also, your developers have to learn quite a bit to manage this well. Tools like dapr reduce the amount of code you need to write, and also do the best paractices for you so your dev team doesn't need to be an expert on 'the cloud' as well.
How does that differ from a Twelve-Factor App[0], which is already an established concept and seems to tackle most of those concerns? I don't think expecting your dev team to know that (or learn it) is too big of an ask.
I feel like especially those factors mainly rely on framework (e.g. Rails) support and I don't see much benefit from an additional library there.
The main value proposition from what I can tell is the one of swappable components, but from my experience with other systems that try to achieve something similar it's likely a flawed one.
E.g. in a lot of ORM libraries you can _in theory_ easily swap your MySQL database for Postgres, but in practice if you actually want to make that transition (which also rarely tends to happen during the lifetime of a single project) it's such a big hassle that you didn't gain much from using the abstracted version. In the meantime you also often have to restrict yourself to the lowest common denominator that is supported by the specific implementations, so you loose out on a lot of powerful features.
Dapr gives you some capabilities that libraries don't have. at first we had the same concerns, but for our use case it works really well. We're using Dapr with Redis and it gives us state versioning using etags which is something Redis doesn't natively have. there's a bunch more features it adds like scoping and consistency.
