if I had a list with 100 ids and had to make an ht...

# coroutines

[João Gabriel Zó]

if I had a list with 100 ids and had to make an http request for each of them, what would be the best approach for doing it in asynchronously?

[flosch]

probably the async builder function but as always in software development: depends on your specific use-case

[João Gabriel Zó]

I need to get the status for each id and update in my database, pretty simple
Was wondering if using map->async and awaitAll on a list would be enough.

[CLOVIS]

`map`→`async` with awaitAll works.

If you want to have a maximum number of parallel operations (e.g. to avoid spamming a server too much), I recommend using Arrow : documentation • parMap • source

[Casey Brooks]

You can also limit parallelism with the Dispatcher, rather than bringing in all of Arrow for that one feature. https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-coroutine-dispatcher/limited-parallelism.html

[uli]

@Casey Brooks, this will probably not work if you use non-blocking IO (Including IO frameworks that schedule to their own threads), as an async network request would suspend the coruoutine an make it not count into the dispatchers current parallelism count

[Casey Brooks]

Yes, but that’s true with pretty much anything you’d do to limit parallelism with coroutines. Coroutines fundamentally aren’t strictly limited to threads, those are just an implementation detail. But what Arrow, limitedParallelism, and other things do is limit the number of active Coroutines. While not strictly limiting the number of active threads, it does limit how many API calls are being run concurrently, which eases the load on the server just the same

[uli]

except for parMap. If I get it right, it limits the “operations”, not the threads, right @CLOVIS

[uli]

But that’s more or less what you say in your second post @Casey Brooks. Just wanted to point out that “limit parallelism with the Dispatcher” would not limit concurrent network request and would not be an alternative to parMap

[CLOVIS]

You can also limit parallelism with the Dispatcher

That's quite a lot more costly than what Arrow is doing

rather than bringing in all of Arrow for that one feature

If you really do not use anything else, you can probably just copy the contents of the methods, it's just the `map`→`async` method with a Semaphore . But honestly, Arrow FX is very lightweight, I would still use the library

[CLOVIS]

While not strictly limiting the number of active threads, it does limit how many API calls are being run concurrently, which eases the load on the server just the same

Actually, it's much more performant, because Semaphore doesn't imply context switching, whereas using a custom dispatcher does.

Also, it works even on platforms where threads don't exist, e.g. JavaScript

[João Gabriel Zó]

I’ve been wanting to use Arrow, but idk if my team is going to agree. I’ll pitch tho
Thanks for the answers, I’ll check the limited parallelism as well!

[CLOVIS]

With regards to Arrow: it's very, very modular, you don't have to start using everything at once! Teams are often worried it will require rewriting the entire codebase, because the recommended patterns are slightly different, but really, you don't have to. If you're already using coroutines, using parMap and parZip , and nothing else, is really not a big deal, and you can start using other things as the team grows more familiar with it.

[CLOVIS]

It's a shame, but teams tend to be afraid of anything with "functional programming" in the name. Arrow is very careful to "feel" like regular Kotlin and let users decide what they want to use or not.

[CLOVIS]

Another good way to introduce Arrow, if you use micro-services, is through the Resilience module.