We released a new version of the SproutCore build tools today. Version 0.9.21 does not contain any of the new bitburger code, but it does include one important change for caching.
Previously, if you looked at the source of your SproutCore applications, you might have seen URL references like this:
/sproutcore/en/javascript.js?1a2ef30ab23980
The number after the question mark is a cache code. It’s purpose was to help web browsers notice when the version of an asset (such as your JavaScript) has changed. This way the server, and caching proxies in between, could store your static assets in cache, reducing the load time for your app.
The problem with this approach (which is commonly used in Rails and other popular web frameworks, by the way) is that some proxies on the web are misconfigured to ignore this cache code if the resource you are requesting ends in a “static” resource extension such as .js, .html, etc. The result was that some proxies would keep your old assets cached when you deployed new versions, even if your cache code changed.
0.9.21 fixes this problem by moving the cache code into the URL itself as a build number. If you install the new build tools and rebuild your application, you will now see URLs like above transformed to:
/sproutcore/en/1a2ef30ab23980/javascript.js
The number included there is actually a build number, automatically generated by SproutCore when you performed the build. This build number will change automatically whenever you change any of your source code. Since this build number is part of your actual URL, proxies will properly load your new content when you deploy it. Problem solved.
Although this change was intended primarily to force the proper caching behavior for all proxies, you now get some extra cool new benefits with the new build tools. For one thing, the number defined above is actually a “build number”. Although SproutCore can calculate a build number for you, if you already use build numbers to track releases internally, you can easily set this build number yourself by passing the –build option to sc-build. See sc-build –help for more info.
Additionally, this new model means that you can now easily deploy multiple versions of a single bundle (such as SproutCore or your app) and they won’t clobber eachother. Each one will end up in its own build.
How to Make the Most of Your Caching
If you are not doing it already, caching support is one of the key techniques used by virtually every large website to maximize their performance. SproutCore is designed specifically to work with this. To achieve the best performance on your application, be sure to set your web server so that all assets EXCEPT for the index.html are served with the following header added:
Expires: <10 years from now>
Consult your web server docs for how to set this header. The <10 years from now> part, of course, is automatically inserted by your web server.
By setting this cache header, you will be telling web browsers and any proxies in between that it is OK for them to download your static assets one time and then to never even ask you for them again. This means that, best case, a user who has visited your SproutCore application one time will the next time download ONLY your index.html file and nothing else. It’s really zippy!
It is important that you not set this header on your index.html files. If you do, then a user may never get an updated version of your application when you deploy it, since you will have effectively told the browser not to check back with you.
How to Get the Update
If you have SproutCore installed already, get the new buildtools by running:
sudo gem update sproutcore,
from the command line. Otherwise, see our download page for more info.
Tags: Uncategorized by charles
1 Comment »
