I'm wondering if it's possible to add HTTP caching for a Goliath API on the
Heroku Cedar stack. Is rack-cache compatible with Goliath and em-memcached,
or is there some other alternative (except running a reverse proxy, which
you can't do on Cedar)?

Thanks,
Bjørn Arild Mæland

Hey Bjorn. Yes you can get rack-cache to work (just need to wrap it to make
it async friendly). Having said that, on heroku you're much better off
making use of their Varnish
cache: http://devcenter.heroku.com/articles/http-caching

Simply emit the right headers and the rest is taken care of for you.

ig

Heroku cedar, which is the stack for Goliath, doesn't use Varnish, FYI.

Sent from my iPhone

On Feb 19, 2012, at 6:16 PM, Ilya Grigorik <igrigo...@gmail.com> wrote:

Correct, Varnish isn't available on Cedar unfortunately. I haven't found
many examples on using rack-cache in an async-friendly way, do you know if
this monkeypatch is still required: https://gist.github.com/743620 ?

Bjørn

Try it - that's the only way to find out :-)

Wasn't aware of the varnish gotcha with Cedar.. Do you guys know why it's
not available?

It has something to do with "advanced HTTP uses" in the new stack.
Perhaps functions that Varnish did not support, such as long-polling,
chunked replies, something like that. The cedar stack has a less
complex inbound request route in order to allow more flexibility in
the dyno layer. But that means no varnish, no nginx. Win some, lose
some I guess.

I'm surprised nobody offers an "Add-On" to Heroku for Varnish.

fastly <http://www.fastly.com/> offers varnish-as-a-service.
 Coincidentally, it's run by Artur.

The main gotcha with Varnish is that, by default, it does not cache
anything with cookies.  Consequently, it takes app knowledge to cache and
invalidate more areas of a site (i.e., profile pages<http://highscalability.com/blog/2011/2/28/a-practical-guide-to-varnis...>
 or login pages<http://highervisibilitywebsites.com/example-varnish-vcl-drupal-pressf...>).
 With memcache farther down <http://rtomayko.github.com/rack-cache/storage>
 the stack<https://devcenter.heroku.com/articles/building-a-rails-3-application-...>,
often there is still load from rendering<http://rubyworks.github.com/malt//> views,
i.e., rendering those all those mustache templates<http://handlebarsjs.com/>
.

A lesser gotcha is streaming spontaneous content (i.e., in-app IM push over
WebSockets), which doesn't make sense for caching anyhow<https://devcenter.heroku.com/articles/http-routing>
.

The ability to customize VCL, specify which pages to cache / never cache
and an invalidation <http://blog.feryn.eu/2010/11/varnish-cache-purging/> API
are the *crucial <https://twitter.com/#!/crucially>* bits. ; )

Ideally though, render views client-side as much as possible in JS from
static cached assets on a CDN and make cheap API calls with Goliath.

Perhaps place Varnish in front of Goliath, which has precedent<http://blog.dloh.org/2011/01/varnish-cache-riak.html> in
non-CDN use-cases.  Request pipelining seems to be the big one.  [Table of
varnish features] <https://www.varnish-cache.org/trac/wiki/HTTPFeatures>

Barry