DEV Community: Cyril Sahula

Dapr in Azure Container Apps

Cyril Sahula — Sat, 10 May 2025 04:06:43 +0000

We decided to use Azure Container Apps as a managed Kubernetes platform because it offers everything we need for our project, with acceptable limitations. During the process, we realised that Microsoft includes managed Dapr as part of the service—and we decided to use it. Why? I explain below—and I still don't regret it.

What is Dapr?

Dapr (Distributed Application Runtime) is an open-source, portable runtime that helps developers focus on coding and delivering business value without dealing with platform complexity or requiring deep infrastructure knowledge.

Dapr showcase

It provides building blocks—such as service invocation, pub/sub messaging, state management, and bindings—for cloud-native development.
The key point? These features are available via standard HTTP or gRPC APIs, abstracting away the underlying infrastructure.
You don’t need to deeply integrate SDKs or libraries. Instead, your service talks to the Dapr sidecar over a local network interface, and Dapr handles the rest. That simplicity is both elegant and powerful.

Cloud-Agnostic for free

Being cloud-agnostic wasn’t our primary goal—but it turns out that Dapr gives us that capability almost for free. It decouples application logic from the underlying infrastructure.
Need a message broker? Use Dapr’s pub/sub API. Whether it’s backed by Azure Service Bus, Kafka, or Redis doesn't matter to the application. The same applies to state stores, secret management, and service discovery. This gives us the flexibility to adapt our infrastructure without touching application code.

Dapr Is Perfect When Managed

In a managed environment like Azure Container Apps, Dapr becomes almost invisible to developers. Azure takes care of provisioning, scaling, and running the Dapr sidecars. There’s no need to manage Kubernetes manifests, sidecar injection, or upgrades.
This “it just works” experience allows our developers to focus on building features, not managing infrastructure. For us, Dapr in ACA became a seamless DevOps-to-code boundary.

Lightweight services

In a traditional microservice architecture, each service often includes direct dependencies on external systems like Azure Key Vault, Azure Service Bus (or Kafka/RabbitMQ), Redis, and others. This leads to increased complexity, heavier containers, and tighter coupling. With Dapr, these concerns are abstracted behind a single, lightweight SDK. The Dapr sidecar handles integrations, allowing the microservice itself to remain lean, portable, and easier to maintain. The SDK is well-supported and actively maintained by a large, vibrant open-source community.

Dapr Can Be Risky When Unmanaged

Dapr is a powerful abstraction—but like any abstraction, it has trade-offs. Running Dapr in an unmanaged environment (such as raw Kubernetes) requires caution. The sidecar must be healthy and synchronized with your app. Misconfigurations, version mismatches, or sidecar issues can lead to subtle bugs or outages.
While Dapr’s tooling is improving, the operational complexity in unmanaged environments can outweigh the benefits. That’s why we only recommend using Dapr where it’s either fully managed or very well automated.

Dapr Moves Infrastructure Dependencies to DevOps

Traditionally, developers had to integrate directly with infrastructure services like queues, databases, or caches. Dapr flips that model. Developers use Dapr APIs, and it’s the DevOps team that configures how those APIs connect to real infrastructure under the hood.
Need to switch from Redis to Cosmos DB? Just change the component configuration—no code changes. This separation of concerns reduces cognitive load and speeds up iteration. Developers gain velocity, and operators retain control.

More Tech Stacks ONE knowledge

Since Dapr communicates over HTTP and gRPC, it doesn’t care what language your service is written in. Whether it's Node.js, Go, Python, or .NET, all services can interact with Dapr using the same approach—via the provided SDKs.
Even in a small project like dream.jobs, we benefit from this flexibility. The backend is written in Kotlin, server-side rendering for the browser is done in Node.js, and AI components are in Python. All services use the Dapr SDK and share a single configuration in the cluster.

Abstraction = some disadvantages

Dapr’s abstraction is powerful, but it’s also generalized. Its APIs are designed to cover common patterns across many tools—which means they sometimes expose only a subset of what a specific service can do.
For example, Dapr’s pub/sub API may not support all advanced features of Azure Service Bus or Kafka. Similarly, its state store abstraction won’t provide full access to things like Cosmos DB’s consistency levels or Redis eviction policies.
That’s a trade-off we accept. For 90% of our use cases, the Dapr API is sufficient. But when we need a specific capability—like dead-letter queues or fine-tuned partitioning—we can bypass Dapr and talk directly to the underlying service. Dapr doesn’t block us; it just offers a solid default.

Final Thoughts

Most of the key benefits and risks are described above, but what I appreciate most is how Dapr helps the team be more efficient. Developers can focus on writing code and solving business problems, while a small DevOps team—even just one experienced engineer—can provide a scalable, secure platform.
In the end, the overall efficiency of your development team can be much higher.

Building immutable collection dynamically in Kotlin

Cyril Sahula — Tue, 22 Apr 2025 12:38:37 +0000

When and Why to Use Kotlin Collection Builders

If there's a requirement to dynamically construct a collection based on certain conditions, two main approaches are available in Kotlin:

Using a mutable collection directly
Employing a collection builder function (e.g., buildSet, buildList, buildMap)

The collection builder approach still uses a mutable collection internally, but the benefit lies in its encapsulation. This leads to cleaner and more concise code, and the final result is an immutable collection.

This post is short and clear although I have met so much mutable collection in projects that is nice to remain it.

Mutable way

It works but collction must be muttable and code is less fluent.

fun mapToWorkTypes(externalTypes: List<String>): Set<WorkType> {
    val workTypes: MutableSet<WorkType> = mutableSetOf()
    if (externalTypes.contains("#001")) workTypes.add(EMPLOYEE)
    if (externalTypes.contains("#002")) workTypes.add(CONTRACTOR)
    if (externalTypes.contains("#003")) workTypes.add(SEASONAL)
    if (externalTypes.contains("#004")) workTypes.add(INTERN)
    if (externalTypes.contains("#005")) workTypes.add(CONTRACTOR)
    if (workTypes.isEmpty()) workTypes.add(EMPLOYEE)
    return workTypes.toSet()
}

Immutable way

The code below uses collection builder. Check documentations of collection builders buildSet, buildList, buildMap.

fun mapToWorkTypes(externalTypes: List<String>) =
    buildSet {
        if (externalTypes.contains("#001")) add(EMPLOYEE)
        if (externalTypes.contains("#002")) add(CONTRACTOR)
        if (externalTypes.contains("#003")) add(SEASONAL)
        if (externalTypes.contains("#004")) add(INTERN)
        if (externalTypes.contains("#005")) add(CONTRACTOR)
        ifEmpty { add(EMPLOYEE) }
    }

Conclusion

Using a mutable collection directly requires more boilerplate and an explicit conversion to an immutable form via .toSet(). It also increases the risk of logic errors, such as accidentally checking or modifying the wrong collection (workTypes vs. externalTypes).
In contrast, collection builders provide a cleaner and more concise alternative:

Less boilerplate
Clearer logic
Automatically return immutable collections
Encourage encapsulated and expressive code

Whenever possible, prefer collection builders for constructing collections based on dynamic conditions.

DDD-like Kotlin object cooperating with Spring context

Cyril Sahula — Fri, 18 Apr 2025 10:22:02 +0000

My friend Dominik helped me figure out which direction to take my coding skills. I never really liked the standard industry patterns that come with the Spring framework, where code is split into APIs, services, and repositories communicating via DTOs, DAOs, etc. I missed encapsulation and clear business objects. Plus, I enjoy both functional and OOP programming, and this layered approach often goes against those principles. DDD is full of abstract rules, but I decided to follow two simple ones:

Domain objects are created on the edge of the domain layer or from another domain object.
A domain object is a real object — it contains both data and business logic.

Kotlin implementation

Sticking to this leads to fluent, readable code that's easy to test and keeps domain problems well-encapsulated. Unfortunately, the Spring framework doesn’t really support this approach by default — it manages beans and stores them in the application context. So the question became: how can I keep clean, OOP-style domain objects while still calling functions that rely on the application context, like opening a DB transaction?
The example below shows that if a function from a bean (usually a repository) is passed into a domain object as a lambda, the Spring context remains available — and even Spring aspects continue to work as expected.

// GraphQl endpoint and edge of a domain layer
@DgsComponent
class DeleteCertificateMutation(
    private val certificateDbAdapter: CertificateDbAdapter,
    private val validator: DomainValidator,
) {
    @DgsMutation
    suspend fun deleteCertificate(id: String): Boolean =
        validator.existsCertificate(id)
            .deleteCertificate(
                certificateDbAdapter::deleteCertificate,
            ).getOrThrow()
}

// Snipped from Certificate domain object 
open suspend fun deleteCertificate(
        deleteCertificate: suspend (CertificateId) -> Unit,
        getSupplier: suspend (CertificateId) -> SupplierId,
    ): Either<NotAdminError, Boolean> {
        // some business logic before like checking right etc.
        deleteCertificate(this@CertificateId).run 
            { supplier.recalculateStatus() }
        true
    }

Of course, there are also ways to avoid relying on the Spring context between the domain and repository layers, but in my case, I needed to use Spring Data R2DBC — probably the only reactive SQL database library that supports transactions — and it relies on aspects.

Conclusion

This approach allows you to have clean, OOP-style domain objects without losing the benefits of the Spring Framework environment.
Domain objects are easy to unit test without needing mocking frameworks — which often lead to brittle tests focused too much on implementation details.
To save time, I still use mock() for method or constructor arguments that aren't relevant to the test itself.