Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caching does not belong in the app #9

Closed
gma opened this issue Jun 15, 2010 · 6 comments
Closed

Caching does not belong in the app #9

gma opened this issue Jun 15, 2010 · 6 comments

Comments

@gma
Copy link
Owner

@gma gma commented Jun 15, 2010

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:

http://github.com/gerhard/nesta/commit/727d9c0a089b430e07dd8b2525c71bea6d876315

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.

@tuupola
Copy link
Contributor

@tuupola tuupola commented Jun 16, 2010

AFAIK with Rack::Cache the requests still go to Sinatra. For maximum efficiency funky caching (Nginx / Apache servers cached static files with rewrite rules) is still the fastest option.

I ended up writing my own Rack middleware for funky caching and have been using that with Nesta since. You can enable it with two lines of code.

require "rack/funky-cache"
use Rack::FunkyCache, :directory => Nesta::Configuration.cache_dir

Source at: http://github.com/tuupola/rack-funky-cache

@gma
Copy link
Owner Author

@gma gma commented Jun 16, 2010

Excellent, thanks. I'll take a look at that.

@tuupola
Copy link
Contributor

@tuupola tuupola commented Jun 16, 2010

Forgot to mention you of course need to setup rewrite rules too. Mine are something like:

# Rewrite index to check for static.
RewriteCond  %{DOCUMENT_ROOT}/cache/index.html -f
RewriteRule ^$ /cache/index.html [L,QSA]

# Rewrite to check for cached page from cached folder.
RewriteCond %{REQUEST_METHOD} ^GET$
RewriteCond %{DOCUMENT_ROOT}/cache/%{REQUEST_URI}.html -f
RewriteRule ^(.*)$ /cache/$1.html [L,QSA]

# Main URL rewriting.
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_URI} !-l
RewriteRule (.*) http://127.0.0.1:4567%{REQUEST_URI} [L,P,QSA]
@gma
Copy link
Owner Author

@gma gma commented Jun 16, 2010

Thanks for that. I may stick it in some docs and attribute it to you if that's okay (I'm in no position to test it though).

In the interests of collecting all the caching thoughts in one place, there's a good discussion in the comments on Kyle Burckhard's site:

http://www.vorpalcode.com/nesta-on-heroku

@gma
Copy link
Owner Author

@gma gma commented Jan 5, 2011

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.

Here's the story: https://github.com/gma/nesta/issues#issue/29

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. :-)

@datenimperator
Copy link
Contributor

@datenimperator datenimperator commented Feb 7, 2013

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.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.