HN Explorer

Ask HN: Caching pages with login form/"Hi, Bob" components

1 points by SoftwareMaven ↗ HN
It has become pretty standard practice to have a login form on every page and, once logged in, to have a "Hi, Bob" type of link to their profile. Naively, this destroys caching.

So what are some ways to deal with this. Ideas I've thought of (with varying degrees of difficulty):

1. Componentize and cache everything on the page in chucnks. Then the final page is a conglomerate of cached chunks. The higher the componententization, the higher the mental complexity but also the higher the potential for re-use.

2. Special case that authentication portion, so the remainder of the page can be cached, but that auth info/form is substituted right before display (that is kind of an ugly, degenerate version of #1). This is pretty easy, but an ugly hack.

3. Use an iframe for the authentication information. Now the page can be cached completely with a simple iframe being regenerated on every request.

4. Use a cookie to store the authentication information and use Javascript to populate it after the page renders. There are obvious problems if a user doesn't use JavaScript.

Are there any other options I'm missing?

2 comments

[ 3.3 ms ] story [ 17.1 ms ] thread
viraptor
I vote for 4, since the user already uses cookies and already has that value. Also it's 2012 - what does "There are obvious problems if a user doesn't use JavaScript." even mean? If they use noscript or something similar, then they won't see "hi xxx", unless they whitelist you. That's pretty much it. (also for most pages, there will be more issues than just the greeting)

1 and 2 work fine if you're doing the caching. Exporting that kind of caching to CDNs may be a bit more tricky (not impossible though...)

jkupferman
37Signals described how they tackled this problem in Basecamp Next (see the "Thou shall share a cache between people" section) http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...

Their solution is similar to #4.

To your concern about disabled javascript, you can still do what they describe but add CSS classes to all elements that would need to be hidden for non-admin/logged in users and just use display:none;

Finally, I would given some serious thought to who the audience is for the application. For most applications the % of users for whom javascript is disabled is so tiny for the amount of work it would require that it is not worth the effort.