views:

35

answers:

3

I'm thinking of implementing my web application in a certain way as an optimization, and I'd like to get people's opinions on whether this is a good idea or not.

Here's the details: For most of my pages, instead of determining server side whether the user is logged in, and then modifying the page I send based on that, I want to send the same page to everyone, this way I can make use of my reverse caching proxy and for most requests not even have to run any dynamic code at all.

The differences that need to be done for logged in users will be done in javascript. The necessary information to make the changes (what their user name is, their user id, and if they are logged in or not) will be stored in a cookie that can be read by javascript.

I don't need to worry about the users not having javascript because my web app requires javascript to be used anyways.

Only the most popular pages that are accessible to both logged in and logged out users will do this.

What do you guys think? Pros/cons? Is this something that websites commonly do?

+1  A: 

Major con: If you are determining what content a viewer can access with JavaScript alone, it stands to reason that a malicious user can potentially access premium content with just a little glance at your source code.

Moses
True, this optimization would only be on pages that are pages everyone can see. The only difference of those pages is something on the top saying "Hi, username", and showing some extra links like user account links.
Kyle
+1  A: 

I'm not sure what you are optimizing really - you need to fetch the user data anyway, and only the server has that. Do you plan on sending an AJAX request requesting for data and using javascript to format it? you are only saving on output generation which is usually not the bottleneck in web application. Much more often the database / IO (files) / network (HTTP requests) are the bottlenecks.

The major con here is that by moving all output generation to javascript, you will increase substantially the download size and reduce overall responsiveness. Since none of the big sites use this approach, you can be sure it doesn't solve scalability problems.

Eran Galperin
For most pages, the only difference is something on the top saying "Hi, username", and showing some extra links like user account links. The only data needed for that is their username, which can be stored in a cookie. I wouldn't be getting the needed data with an AJAX call. For the pages that were heavily user based, like the user account page, I wouldn't even use this method at all.
Kyle
In that case you are optimizing something that will never be a performance problem. For the more dynamic pages, you are just complicating your setup
Eran Galperin
@Eran - I'm running on GAE. Pages that I am able to send with `Cache-Control: Public` are cached on proxies geographically close to the user. Even without the geographic benefit, serving a request dynamically on GAE, with no DB access, takes about 50ms, serving statically takes about 2ms.
Kyle
clarkf
+1  A: 

Doing it for 100% of your application would be a little problematic, however, it sounds like you are seeking to use something called the Model-View-Presenter pattern:

http://en.wikipedia.org/wiki/Model_View_Presenter

Be wary that, when using javascript, your code is exposed, meaning that any security measure taken is potentially hackable through the browser. Add protection on the server side and you are set.

Also, since you are going to rely heavily on javascript, I really recommend you using Mootools, which is an object-oriented approach to javascript. That way you can keep your code really modular, work around messy implementations using custom and class events, etc.

dukeofgaming