

Bulletproof Rails Asset Caching - 2is10
http://eng.wealthfront.com/2011/02/bulletproof-rails-asset-caching.html

======
bradgessler
Compass/SaSS + AssetFingerPrint + jammit is a great way to what wealthfront is
doing.

Compass has helpers that use the Rails asset link helpers to link to images.
There are sprite helpers available as well.

AssetFingerPrint is a Rails plugin that tosses and MD5 into the asset link
automatically.

Jammit compresses CSS/JS files, and the fingerprint of the resulting compiled
files are picked up by AssetFingerPrint.

Thats how we roll at Poll Everywhere.

------
lamby
It's difficult for this to not sound snarky, but my definition of bulletproof
doesn't involve parsing CSS with bash and awk.

~~~
purp
<snark>You'd prefer C?</snark>

Seriously, though, how would you improve the solution? What would decrease the
likelihood of serving the wrong asset or no asset at all? I'm sure there are
other interesting solutions to this problem, but are they as complete and in
some measurable way better?

Disclaimer: I work with Jared and enjoy the benefit of the solution as
described.

------
rst
Looks interesting. Pre-generating asset files for deployment might also be a
nice alternative to the usual tricks[1] for using SASS (or other CSS
generators) with Heroku, which have rack middleware reading a cache.

(Unfortunately, the code samples were a hard for me to read, in both Firefox
and Chrome --- all the newlines seem to have somehow gotten squeezed out...)

[1] <https://github.com/pedro/hassle>

~~~
Oompa
I believe that in Rails 3.1 they're including a fix for this, so work arounds
like this won't be necessary anymore :)

~~~
2is10
Got a link to details? I'd be surprised, since any correct solution requires
two-stage deployment and keeping old assets around. These capabilities are
beyond the scope of a web server framework. The Rails team could certainly
educate Rails developers and choose conventions that make correctness easier.

------
mrkurt
Sprockets 2 (not yet a gem, point to git) makes a lot of this easier. You can
put extra extensions on your files to get them processed with ERB or similar
before they're served, so you can actually append auto generated asset
versions to URLs in CSS files if you want. It also sends appropriate status
codes when there's a stale version (410 Gone).

Sprockets 2 behind Amazon CloudFront does asset handling almost exactly like I
want it done.

~~~
2is10
But any dynamic processing of stylesheets sacrifices performance. It means
they have to be served by Rails. Preprocessing before deployment frees you to
host them anywhere, ideally closer to your users.

~~~
mrkurt
I get exactly that with CloudFront, a custom origin (with Sprockets), and
appropriate HTTP headers. If CloudFront doesn't see a file, it asks Sprockets
for it and caches it however long I tell it to.

You can do the same with Varnish if you don't want to use Amazon's CDN. Having
run a large site with prebuilt assets for several years, I really enjoy not
having to do it anymore.

------
hkarthik
Great post with lots of good info. Especially important for apps that utilize
a lot of JavaScript. We've been getting bit by this lately in ASP.NET MVC
since it has no built in strategy for dealing with browser asset caching/
expiration.

