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: http://www.effectiveskiing.com
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 :)