Mutiny integration with Kotlin Coroutines

[imrabti]

Is it possible to use Mutiny with Kotlin Coroutines ?

[jponge]

There is no specific integration. Do you have any use-case?

[imrabti]

With Vertx there is the ability to run vertx code in the Coroutines scope as below :

CoroutineScope(vertx.dispatcher()).launch { // some vertx code }

Is it possible to achieve something similar ?

[jponge]

This has to be investigated

[nkhoshini]

You can convert a Uni to a CompletableFuture and then use the kotlinx-coroutines-jdk8 library to convert it to a coroutine
uni.subscribeAsCompletionStage().await() or
subscribeAsCompletionStage().asDeferred().await()

[heubeck]

Hey people,
also looking for a smooth way for using "the Quarkus stack" with Kotlin, mainly the reactive routes and of course Mutiny with a lots of Vert.x in between.

Where would be the right place for providing utility functions on Uni and Multi but also other Quarkus or even Vert.x types to make a Kotlin native developer experience by writing imperative (coroutine) code?

Obvious cases are:

• suspend Uni.await
• Multi.toChannel
• suspending executors around RoutingExchange using the Vert.x coroutine dispatcher

Are these cases worth an own library, project by project? Or could it be part of the Quarkus Kotlin extension?

[cescoffier]

For the 2 first items, we should be able to create a module in mutiny directly. For the last one, it would be in the Quarkus extension (not sure which one).

[heubeck]

Would love to start or contribute to a smallrye-mutiny-kotlin module.

How to organize this - since hopefully others will support too (@imrabti ?)?

Just create a fork open to write for everyone?

Since that new modul would give a good dependency for quarkus-kotlin, we can have a look to that afterwards.

[cescoffier]

@heubeck Just create a fork and a PR opened to everyone.

[heubeck]

With PR #419 I'd like to implement the following "extensions":

• Uni.awaitSuspending -> retrieve the item or raise the failure
• Deferred.asUni -> create a Uni from that Deferred
• Multi.asChannel -> stream the items or failure of the Multi to a newly created Channel
• Channel.asMulti -> the other way around
• Multi.asFlow -> Flows seem to fit better than Channels, so a Flow matches a Multi semantically
• Flow.asMulti -> the other way around

Name of the functions is subject for discussion.

Please have a look in the PR for details and of cause reviews.

[cescoffier]

I like the names!

[heubeck]

Had a talk with @bartwinski who suggested to use Flows instead of Channels (thanks for the hint).

Haven't worked with Flows yet but from the documentation they sounding much more like Multi / Reactive Streams than Channels which are more like a technique to communicate between coroutines.

Since I'm struggling with overflow issus in the Multi.asChannel implementation and Flows seem to solve buffering different, I'll change to Flow.

[heubeck]

PR #419 is now ready for review.

[heubeck]

@imrabti @bartwinski
As my implementation was accepted by the project, can you please test (after the upcoming Mutiny release) whether your needs are fulfilled and how it works out in real world projects, will do the same by myself.
I will welcome further improvement and additional function requests for come Mutiny and Coroutines close together.