Think of a coinflip game, whose logic looks as follows:
- Server sends websocket message (RESULT_MESSAGE) to frontend with result of a game (won/lost)
- Server sends websocket message to frontend with updated aggregated stats (STATS_MESSAGE) (think all-time profit after the new coin flip, or updated all-time stats)
- Frontend reacts to RESULT_MESSAGE by playing an animation (coin flipping). It also updates the all-time stats and profit in response to STATS_MESSAGE
The problem with this logic is, responding to STATS_MESSAGE (updating profit and stats) gives away the result of the coin flip before the animation finishes.
Solutions I cannot use:
- Merging RESULT_MESSAGE and STATS_MESSAGE together, and only updating the stats/profit after animation finishes. Because those 2 messages are produced and sent by different services.
- Linking a particular RESULT_MESSAGE to a STATS_MESSAGE and only reacting to a STATS_MESSAGE when its corresponding RESULT_MESSAGE has been processed and its animation completed. Because in reality I have several kinds of STATS_MESSAGES (trophies updated, stats updated, profit/balance updated, etc), and it's just not practical for the frontend to hold onto all those messages until their respective RESULT_MESSAGE is processed
Solutions I've tried successfully before, but I'm trying to avoid:
- Having the backend send STATS_MESSAGE with a delay, to make sure it doesn't reach the frontend before the coinflip animation has finished. This sort of encodes frontend behavior (animation) on the backend.
All ideas and suggestions appreciated. Thanks a lot!
EDIT: I made the coin-flipping example for simplicity, but it's not precisely con-flipping. It's a multiplayer game where dozens of games/animations per user per seconds are going on. So queuing a bunch of stuff on the frontend might be less than ideal (I'm still looking into performant versions of this solution though).
Pulling the STATS data via an API call when the animation finishes (instead of using websockets data) is another alternative that I've considered, but for the same reason described above it might not be feasible (dozens of API calls per user per second). Plus there's a chance that an API call is triggered by
game-1 finishing, but while
game-2 animation is still going on, giving away the result of