A long time ago, I took over a web app that was one of the most critical parts of our technological risk management platform–the trade monitoring UI. I made changes on a rather dilated release cycle, usually pushing non-critical enhancements into prod after thorough vetting in a simulation environment and, as I often joked, after a certain amount of prodding.
Using this web app, a user with sufficient privileges could start, stop, and, most importantly, kill trades. This was the first (and, by far, the most effective) line of defense against an application gone awry.
One day, the time came to release a thorough refactoring of the code. At that point, I was of the opinion that refactoring often isn’t worth the time or risk, but I was determined to give it a shot anyway. I released and slowly tested most of the features. Everything was going well. I finished my testing, gave the virtual thumbs up, and began my daily turndown before leaving the office. Then I received a message: “Hey Tim, nothing happens when I kill a trade.”
I needed to cache bust.
To help build intuition for what gets cached, go to your favorite website and open the Chrome developer tools console. Then, navigate to the network tab and refresh the page. This will show the full query URLs with information differentiating those that were loaded from cache from those that were loaded dynamically. It’s a feature I’ve been using on a more regular basis, as one of the WordPress pages that I manage for a side business was at one time perhaps the slowest site on the internet.
Generally, you want to cache. Caching is good; slow site loading is bad. If you disagree with me, though, the first thing you can do is implement one of the methods discussed in this StackOverflow question. It’s a heavy-handed method but it should work.
<script src="myApp.js?random=<?php echo uniqid(); ?>"></script>
which evaluates to:
Go ahead, refresh the page.
The key part of the above method is the query string beginning with the question mark. If this is different from what’s cached, the browser will reload the resource. I ended up using a less dynamic approach that preserved the cache until the next release. I modified a statement like the one above and instead provided the tagged version as the parameter. For each new release, I just incremented the version number. This forces a cache bust for each release. This is a well-documented approach, but by writing this post I hope I can save one person the pain of forgetting to cache bust a critical application. Thanks for reading.