More of a personal observation than a question. I've noticed as soon as you start using coroutines a...

# coroutines

[Edoardo Luppi]

More of a personal observation than a question.
I've noticed as soon as you start using coroutines and suspending functions in internal code it becomes increasingly difficult to make the code interoperable with platforms like JVM and JS.
How do you guys manage to decouple coroutines from exposed code in a good way?

[xoangon]

Not 100% sure if I understood your question properly, but there are mainly two functions in the coroutines library that you should know when working on providing interoperability with blocking asynchronous frameworks:

• `runBlocking`: It starts a new coroutine that will block the thread on which it's run. You can use runBlocking(<http://Dispatchers.IO|Dispatchers.IO>) for blocking network operations
• `suspendCancellableCoroutine`: This function allows you to wrapp a callback and translate it to a suspend fun by manually managing the underlying CancellableContinuation

[Advitiay Anand]

I think keeping your suspend functions / coroutines in a platform-specific layer is the way to go. Maybe?

Don't know about JVM but surely coroutines can't work with JS. The whole async logic has to be different.

Happy to be corrected tho.

[Johann Pardanaud]

You should keep your coroutine code in the common target and expose an API specifically designed for each target.

For JVM, you can use asCompletableFuture to create a future-based API.

For JS, use asPromise to create a promise-based API.

[Edoardo Luppi]

I'll explain what the problem is in more details later this evening.