It made sense (pragmatically) to put file based caching in Nesta when it was in it's infancy, before the sinatra-cache gem really worked properly, and before Heroku was a viable deployment option. Now it just seems bizarre that caching behaviour should be baked into the app.
Would it be better to use Rack::Cache? Here's a patch from Gerhard:
File based caching is a great option for people deploying with Nginx, but the current behaviour seems to cause confusion. This comment was posted to a blog running Nesta:
I find it odd that Nesta does this cachine but the official documentation makes no mention of needing rewrite rules or anything. It gave me the impression that the app itself handled the work with regards to whether or not to serve the static html or not.
That said, anyone seen any nginx rewrite examples for this around?
I think it's time to switch the file based caching from lib/cache.rb to sinatra-cache.
The text was updated successfully, but these errors were encountered:
One of the reasons I held off on updating the caching code for so long was because it wasn't clear to me how best to implement it, and I've had some great (but different) suggestions from plenty of people about how to achieve it.
However, I'll be working on a plugin soon that just won't work without you being able to set the max-age header independently for different pages, so I'll be adding some optional Max age metadata that will be used to set the Cache-Control header.
I'm not sure if I'll do anything with etags/last_modified or not yet; it'd be nice, but until I come up with an API/config file format that is flexible enough and clean enough, I'll hold off on that part.
In the meantime I'm closing this ticket, as I now have a plan. :-)
Funny to read this discussion here. After just one day working with nesta I was wondering why you'd put in your own caching but not the Sinatra module. I was just about to provide a patch :-)
To my understanding, caching belongs not to the app but to the servers in front of it. The app should provide meaningful meta information (using http headers, that is) to allow proper functionality. If frontend caches decide to let the request fall through to the app again, it might be for a reason and the app does well in general by responding with a fresh, non-cached result.