Rack::Cache is a good idea
Fellow Ryan, Mr. Tomayko has recently released a new project, Rack::Cache that I think is a great idea for ruby web developers.
This problem has actually been bothering me for awhile, too, but I could never articulate it well enough or think of a useful solution to it.
The problem is that if the application is small and new, its rarely worth the effort to deploy an caching http proxy, yet you can still get significant benefit from something that caches entire resource (an entire page, rather than just the data that goes into rendering that page). As a result, Rails allows you to use a page cache, which writes the files to a filesystem and lets a dedicated web server serve them, without consulting your web application.
This system works fine if your cache policy is simple enough to manage it explicitly, your application has access to the same filesystem as your web server and you’re only running a few servers. Also, it can be tricky to get your web server configuration right on this front.
Once your application gets larger and more complex, it makes sense to use an http reverse proxy cache like squid or varnish, but transitioning from rails-style page caching to HTTP caching is non-trivial. You have to change your deployment and your application in significant ways. Not fun.
With Rack::Cache you only have to change your deployment. You can even do it incrementally. You could start by using Rack::Cache to cache in the heap, later switch to the filesystem and finally to memcache. When that reaches its scalability limits you can add squid or varnhish in front of your application, then remove Rack::Cache. Deployments that involve only one major change at each step are much easier to get right than trying to make several big changes in a single operation.
