Most apps are web-based these days, user facing and data-intensive.
It is a common pattern to launch (reactively) some requests for data (to a database, other micro-services etc), aggregate the responses and present them back.
When you struggle to wait and re-compose these bits and pieces, using streams, observables, actors, continuations, Futures or other reactive flatMaps, don't forget where the buck stops: the browser.
Here's a really lazy counter...
<span id="counter">...</span>
<script async>$("#counter").load("/api/wix/realm/count");</script>
Yup, it is that simple, using jQuery. This will go back after most of the page is rendered and fetch a counter value and then display it, in a place reserved for it.
See it in action here (right click and see the html source):
I hate JavaScript-ladden pages that keep re-drawing themselves and dancing in front of your eyes, as much as the next guy, so make sure you don't abuse this. Make sure you size and/or place the span/div targets in such a way that the page doesn't have to change too much when the result arrives.
It can however simplify a few things - especially, i am shamed to admit, getting the request again, which is often not available in some re-used Play template... heh. Note that with SPA-type apps, this is much more common, since the templates reside on the client.
There's of course the cost of the extra call and round-trip, which you have to weight against the cost of getting the info as well as the cost of being lazy :)
Enjoy!