If you need to make 4 API calls concurrently, but ...

# coroutines

[Remy Benza]

If you need to make 4 API calls concurrently, but 1 of the API calls depends on data from another. What would be the best pattern?

[Remy Benza]

fun getLiveGameData(viewScope: CoroutineScope) {
    viewScope.launch(<http://Dispatchers.IO|Dispatchers.IO>) {

        while (isActive) {
            // make the 4 API calls concurrently
            val fixture = async { payPerViewRepository.getNextFixture() }
            val liveVideo = async { payPerViewRepository.getPPVLiveVideo()?.liveVideo }
            val showLiveGame = async { payPerViewRepository.getPPVToggle()?.showVideo == 1 }
            val liveMatchInfo = async {
                // get id from Fixture first to make API call for live info
                val matchId = fixture.await()?.id.orEmpty()
                payPerViewRepository.getLiveMatchInfo(matchId)
            }

            val data = PayPerViewLiveGame(
                liveVideo = liveVideo.await(),
                fixture = fixture.await(),
                liveMatchInfo = liveMatchInfo.await(),
                showVideoPlayer = showLiveGame.await()
            )

            liveGameData.postValue(data)


            delay(Duration.ofSeconds(10).toMillis()) // poll every 10 secs
        }
    }

[Remy Benza]

my current code ⬆️

[Remy Benza]

the 4th API call liveMatchInfo relies on the first API call that returns a fixture object

[Remy Benza]

is this a good pattern? or should I just use something like this:

val liveVideo = async { payPerViewRepository.getPPVLiveVideo()?.liveVideo }
val showLiveGame = async { payPerViewRepository.getPPVToggle()?.showVideo == 1 }
val fixture = payPerViewRepository.getNextFixture() // suspend here to wait for result
val liveMatchInfo = async {
                // get id from Fixture first to make API call for live info
                val matchId = fixture.id.orEmpty()
                payPerViewRepository.getLiveMatchInfo(matchId)
            }

[Remy Benza]

In that case the coroutine will suspend until payPerViewRepository.getNextFixture() returns

[Remy Benza]

so maybe less performant?

[krzysztof]

what about moving fixture to same async call, where it is needed as argument?

val liveMatchInfo = async {
                val fixture = payPerViewRepository.getNextFixture()
                val matchId = fixture.id.orEmpty()
                payPerViewRepository.getLiveMatchInfo(matchId)
            }

[Remy Benza]

then async no longer returns deferred

[christophsturm]

i think all 3 versions perform the same

[krzysztof]

then async no longer returns deferred

Not exactly following, You mean call to async {} won’t return you Deferred?

[Remy Benza]

I need the fixture object outside of the asycn scope too

[krzysztof]

ah, make sense, haven’t notices it’s required in other async too

[krzysztof]

then I think, like Christoph said, it’d perform the same

[christophsturm]

i think the most readable version is to make only the liveVideo and showLiveGame calls async

[Remy Benza]

I have this now

[Remy Benza]

message has been deleted

[christophsturm]

hmm but that code assumes that await returns null when its not ready, but await waits until the result is ready

[Remy Benza]

all API calls return null when an error comes back

[christophsturm]

ah ok

[Remy Benza]

maybe `liveMatchInfo`doesn't need to be an async coroutine

[christophsturm]

you can just make liveMatchInfo not async, because you start it async and then await it

[Remy Benza]

since it's the last call and liveVideo and showLiveGame are already running concurrently right?

[christophsturm]

or in other words because async { xxx()} .await() is the same as xxx()

[Remy Benza]

yes, true. Thnx

[ursus]

Why not treat it as 3 concurrent ones?

[Remy Benza]

whats your suggestion to make it better?

[ursus]

I didnt read the whole thing but Id treat it as concurrent(a, b, sequential(c,d))

[uli]

I’d go with the first version as it is most straight forward. all four async, all four awaited where ever they are needed.

No deeper knowledge about any details needed to understand what’s going on.

No reasoning why one of those can be just a suspend call.

No reasoning to break if you change the order of fiering those requests.