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

Already on GitHub? Sign in to your account

Watch files cache #536

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
2 participants

manast commented Apr 13, 2012

Hello,

I added a small improvement to the staticCache in order to listen for changes of files. So now, even if a file is cached, as soon as it is changed in disk, it will be removed from the cache.

The changes are performed on top of 1.8.6, since thats the latest version that works with the stable branch of express, but it should be trivial to merge this changes to 2.x.

regards,

Manuel.

Member

tj commented Apr 13, 2012

this is not how a reverse proxy cache manages freshness, it delegates back to static() when necessary depending on the cache-control, staticCache isn't really a "true" proxy cache but we should treat it the same

@tj tj closed this Apr 13, 2012

manast commented Apr 13, 2012

ok. can you elaborate more why we should treat it the same as a proxy cache?.

Btw, whats your opinion on the other experimental commits? I found this to be extremely convenient, I get all my javascript files minimized, less files compiled and gzipped on the fly without any performance penalty since the results are later cached. And due to the watchfile I don't even have to care about freshness, it is handled automatically...

Member

tj commented Apr 13, 2012

Well ideally we dont have experimental stuff in here at all, that being said staticCache alone is somewhat experimental, more so than any of the others for sure. Its purpose is to act as a reverse proxy cache, in-process, since that's often more convenient than setting up varnish etc. http cache mechanisms dictate when resources become stale

manast commented Apr 13, 2012

Sure, the experimental stuff was just as a proof of concept, I was not aiming for a pull. Do you have any feedback on that kind of functionality? If you are positive I could invest some time in making it production quality.

About the watchfile. I understand that you want to keep in staticCache the same philosophy as in a standalone reverse proxy, but since you actually can track changes of the modified files I don't see any practical reason not to do it. A real reverse proxy can not keep track of the modified files so it has to relay on client side. The watchfile mechanism is very useful also in development, although you could argue that the cache does not need to be enabled I think the closer your development env. to your production, the less bugs you will have in the end.

On 13 apr 2012, at 18:12, TJ Holowaychuk reply@reply.github.com wrote:

Well ideally we dont have experimental stuff in here at all, that being said staticCache alone is somewhat experimental, more so than any of the others for sure. Its purpose is to act as a reverse proxy cache, in-process, since that's often more convenient than setting up varnish etc. http cache mechanisms dictate when resources become stale


Reply to this email directly or view it on GitHub:
#536 (comment)

manast commented Apr 13, 2012

After a bit more of thought, I think that all the mechanism you use to bypass the cache with the cache-control header becomes fully irrelevant with my approach. You will get exactly the same result no matter if you want to bypass the cache or not, since the cache has always the most updated resource... So this code can be deleted, and I am sure it will even reduce latency a bit. :).

Member

tj commented Apr 13, 2012

it's just that cache-control and the validation fields are designed for these cases, so coding around them seems suboptimal

manast commented Apr 13, 2012

I cannot see how it can be suboptimal to always deliver correct updated files versus potentially outdated cached results, not to mention that I can get rid of some extra code complexity... I really would appreciate if you can explain that to me, because certainly I am missing something important here.

Member

tj commented Apr 13, 2012

because the entire http cache system is in place to deal with things and invalidate caches in a specific manner, if you dont want something cached for a long time just dont cache it for a long time and the conditional gets will fall through

manast commented Apr 13, 2012

yes, the system is designed to allow proxies or browsers to have suboptimal caches because it is imposible to do optimal since you never know when some cached element will be invalid. But in the case of the staticCache middleware you can know when something is invalid precisely, so you can do it in an optimal way if you want and besides using a simpler mechanism. I really dont see the point of following a standard when you can do it better without following it.

Member

tj commented Apr 13, 2012

because that's not the goal of the middleware. "ideal freshness" is entirely app-specific as well, if I say something has a max-age of an hour, then I really dont care if it's stale or not, I dont want staticCache behave differently, for some people that may be a different story, but then why not adjust your caching technique using these existing mechanisms

manast commented Apr 13, 2012

The thing is that it is not behaving differently when you don't care, but is behaving right when you care...

On 13 apr 2012, at 21:32, TJ Holowaychuk reply@reply.github.com wrote:

because that's not the goal of the middleware. "ideal freshness" is entirely app-specific as well, if I say something has a max-age of an hour, then I really dont care if it's stale or not, I dont want staticCache behave differently


Reply to this email directly or view it on GitHub:
#536 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment