Wait you say, what are ETags? As the name implies, they are a way to tag a resource for later identification. Imagine a visitor browses your homepage, and you dutifully fulfil the request. But before you send the page off, you tag it with a unique ETag header. Now, when the visitor visits your homepage again they send that ETag (as an If-None-Match header... go figure) to your server. From there, you compare your homepage's current ETag to the one they sent. Do they not match? Ok, send the page again with the new ETag. The magic happens when they do match, allowing you to skip sending the (kilobytes of) page data and instead just return a 304 Not Modified status code. Bandwidth savings and a speed bump in a nice pretty bow.
Rails takes advantage of ETags using the
fresh_when controller method
(or it's control flow brother
stale?). In the show action of the
fresh_when @user will compare ETags against that
cache_key, a method that returns a unique string for an Active
Record object. If they match, Rails will stop the expensive rendering
and return that pretty 304 status code.
But then why are developers stress testing tables with their heads?
That's due to Rails' nasty little gotcha,
fresh_when doesn't even
consider changes to the view code. Do you clear out your old assets when
are trying to pull down assets that don't exist anymore, all because
your ETags are telling them the page is the same (and thus using the
That's why we are releasing the Ettu gem, Latin for 'And compute you, too?'.
into the ETag equation, giving you peace of mind that your ETags will
always be up to date with your current deployment. And it does all this
while allowing you to use the same
fresh_when syntax you're already
used to. So keep doing what you're doing, and let Ettu worry about
your view code.