HTTP caching for Goliath API on Heroku

[Bjørn Arild Mæland]

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

[Ilya Grigorik]

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

[Joshua Warchol]

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

Sent from my iPhone

[Bjørn Arild Mæland]

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

[Ilya Grigorik]

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?

[Joshua Warchol]

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.

[steakknife]

fastly 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 or login pages).  With memcache farther down the stack, often there is still load from rendering views, i.e., rendering those all those mustache templates.

A lesser gotcha is streaming spontaneous content (i.e., in-app IM push over WebSockets), which doesn't make sense for caching anyhow.

The ability to customize VCL, specify which pages to cache / never cache and an invalidation API are the crucial 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 in non-CDN use-cases.  Request pipelining seems to be the big one.  [Table of varnish features]

Barry

On Tuesday, February 21, 2012 10:41:05 AM UTC-8, Joshua Warchol wrote:

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.