When we work with EventSourcing, the only source of database changes is events (yeah, sounds good, right). One of the truly great advantages of this is that there’s absolutely no need to hassle our servers for realtime change information with heavy SQL operations, or even lighter NoSQL ones. No need of rethinkDB from our back, or simple queries from the front. Just follow the events as they are and push them to the frontend side. From that, when we load pages, we cache them for later calls and just supervise events that could invalidate the cache (not that much, for each one), telling us which pages should now be reloaded via AJAX calls. Ex: UserPortraitWasChanged event received by the frontend side would invalidate its /profile page cache.

For the events conveyance (back to front), we use the ws:// protocol (JS tool: socket.io).

We preload pages when the user "mouseover"s the platform links. Clicked on, these links will then provide a cached result. Of course, all this stuff only works with a PWA: AJAX calls for pages navigation, not browser reloads! (Remember: only JSON payloads via these calls, never raw HTML, which must be built afterwards, and only afterwards).

In the video, you'll see that there was only two AJAX calls (Laurence Bloch, Guillaume Meurice). The rest is completely cached.

You may have noticed that the gain, of having cached pages and avoided later calls of these same pages upon servers, is eventually lost, because we preload pages and some could be useless (user never following some links). That's fine with me, personally. Because, besides, the user has saved 40% of navigation time! No special good for us, but quite important one for the user. 😌

It’s like an online game. The pages are the environment of the player (the user), already there and ready for interaction (without the huge drawback of really loading all, since it is progressive), and they’re updated when events occur. Navigation becomes a true house visit, no more waiting time between the rooms. Have a look at a sample code!

...a website behaving like a game, isn't it beau-ti-ful?

Notes:
- dev.to uses very similar techniques!
- sample code is simplified:
---> mouseover is limited to the strict boundaries of each < a > element, but we could also do preloads when the user enters a larger zone (ex: < a > + 240px edging). When the user enters a page, it's like having the page plus all the links of it loaded, but in a optimized way (loading only done when user is not very far from clicking).
---> we could use window.localStorage or window.BroadcastChannel to share pages cache to all tabs/windows of the browser, until the user close it all.