Keep Your Vue Apps Fresh, Revisited

Users rarely refresh long-lived single-page apps. Here’s how we detect new releases and quietly reload idle tabs without losing anyone’s work.
In a single-page application (SPA), users have no idea a new version is available unless they refresh the browser, which they rarely do in a long-lived app with client-side navigation. For three years we’ve run a solution (outlined here) that works well. The server reports its current version, the frontend knows what version it was built with, and a banner shows when they differ.
Our use case is internal tools that stay open for a long time. I don’t think this has much value for quick-visit web apps, because you’d naturally pull down the new version when you came back. However, when a tab could stay open on your computer throughout the day, or even throughout the week, being able to trigger refreshes is critical.
There have been seven main changes since the last post:
Prior to this update, the polling went to the main /graphql/ endpoint that was guarded by authentication checks. This caused two problems:
We moved the version query to our existing public endpoint, /public-graphql/, which skips the session and user lookups.
All we fetch is a version string. Apollo was more machinery than we needed for this. Switching to fetch gave us more control over the timing of the polls.
We switched from a fixed 15-second poll on every open tab to a backoff that stays at 15 seconds while the user is active, doubles while idle, and resets to 15 seconds on any mouse or keyboard input.
Since nobody is going to click a reload button on a banner in a tab they aren’t looking at, we reload the page if the user has been idle for more than 15 minutes.
A tab left idle long enough can end up with a stale CSRF token and get a 403. When that happens, we reload it.
We found the bundler sometimes created multiple copies of the module, and with them multiple timers. To prevent this, we keep the version check state in a singleton on the window object.
If a new release is out and you navigate instead of clicking the banner, we do a full page load instead of client-side navigation, which pulls down the new version.
Rather than doubling forever, the backoff caps at 5 minutes. Without a cap, an inactive page could quickly drift to polling hours apart, which helps no one.
Browsers slow down timers in hidden tabs, so we also check when a tab becomes visible. If a release came out while the user was away for more than 15 minutes, the page reloads as soon as they return.
We skipped WebSockets and SSE because a release notice doesn’t need to arrive within seconds. The pain isn’t worth the new infrastructure. We skipped Service Workers because they solve offline caching, which we don’t need, and they make updates harder to control. And we don’t reload the moment a release is detected, because that could throw away a user’s unsaved work.
The banner pops in at the top of any page when a new release is out, with a link to reload.
The original version kept working, but these changes make it smoother. They came from watching how people actually used the software day to day over the past couple of years.
These are improvements that would likely never see the light of day in the era of hand-written code. But now we can point agents to fix and improve things. Nothing is too small or too low priority to be worth doing anymore.
More posts Website XLinkedIn
Engineering and agronomy write-ups, sent when they're published. No spam.
Almost there. Check your inbox to confirm.
Django Nov 10, 2025 7 min read
Learn how we integrate Vue and Django for a bullet proof deployment.
Django Oct 22, 2025 3 min read
How we query our GraphQL API directly through Python avoiding duplication of query logic and overhead of web requests.
Vue Oct 15, 2025 3 min read
Keeping your Vue SPA up to date when new code is released.
© 2026 Wedgworth’s, Inc. Belle Glade, Florida. Since 1932.