Kotlin Flow is a powerful reactive stream processing tool. Although not strictly based on the Reactive Streams specification, it’s fully interoperable with it, and since it leverages coroutines, it makes it an incredibly fun tool to use. However, it is still not widely used for enterprise integration. I’m here to explain the whys and talk about how you can overcome these limitations and use Kotlin Flow as an ally when you’re building enterprise integrations.

Many asynchronous libraries in Java still do not support CompletableFuture, which often leaves us dealing with the traditional Java Future. The problem is that it lacks of callback methods, forcing us to block the execution to get a result, something that is far from ideal.

As we all know microservices have become a huge trend that can’t be ignored. With their help, we can effectively decouple our systems, making them easier to test and manage. Beyond the well-known HTTP protocol, there are several other protocols and content types can be utilized to create APIs. Today, I’d like to share an experience about crafting APIs using AMQP, specifically with RabbitMQ (or any other message broker supporting AMQP 0.9.1).

As developers, we love solving intricate problems, and let’s be honests, we love proposing intricate solutions as well. However, many of these problems have already been addressed by other people before us. Why should we spend time reinventing the wheel when we could leverage solutions that have proven their efficacy time and time again? This is where design patterns come into play.

Polymorphism is one of my favorite things from object-oriented programming. It’s the ability of an object to take on many forms, allowing for flexible and efficient code execution. The beauty of polymorphism is that it can facilitate various behaviors in software without the explicit need to define each one in the code.