Don't Throw Away Your Old Java Web Framework: the Short Single Page History of Twitter
Twitter.com is one of the most popular websites in the world, few people know that is also one of the few Single Page Interface, stateless, SEO compatible websites in the world.
Twitter is SPI in the sense that it prevents fully loading pages; each click implies a partial change of the page without loading a new page, with the necessary data obtained through AJAX.
It is "stateless" in the sense that Twitter ensures that servers do not have information of the status of the user page loaded, that is, web session data. This allows requests to arrive at any node of a server cluster without sharing sessions or needing server affinity. Looking at the AJAX requests Twitter sends an id representing the temporary state of the user's page saying something like "previous stuff is already loaded, I want new things".
As we will see later, this SPI approach is server centric or hybrid (even though it has a lot of programming client), but Twitter has not reached the current implementation in the first attempt, there was previously an SPI client centric implementation.
First version: client-centric
We all know Twitter's REST API, which returns user activity data in JSON format. This API was very popular in alternative Twitter clients until the company introduced limitations that harmed the popularity of these readers. By then the Twitter website itself was a consumer of it's own REST API so that the browser was a real Twitter client for logged in users...
The title "client-centric" means that the HTML is rendered from data. Where and when HTML is rendered from server data is the big architectural part of a web application, in this case it is the client.
Hashbangs are also SEO compatible because Google has been supporting them since some years ago.
When Google sees: http://twitter.com/#!jmarranz
Google will load: http://twitter.com/?_escaped_fragment_=jmarranz
Second (and current) version: server-centric (or hybrid)
At the same time one of the key developers of the client-centric SPI Twitter left the company for a startup.
Just aT the end of the Twitter blog entry it seems to be a light and hope for SPI:
"What’s next? We’re currently rolling out this new architecture across the site. Once our pages are running on this new foundation, we will do more to further improve performance. For example, we will implement the History API to allow partial page reloads in browsers that support it, and begin to overhaul the server side of the application."
Dan Webb's response deals with the fact that that although there seems to consider some partial updates made via AJAX but not using hashbangs, using the History API instead (not possible for instance in IE 6-8 browsers).
The last tweet says:
"we made our perf decisions based on data. It's not about liking or not liking a technique. It's about what we prove is fastest."
The current server-centric (or hybrid) SPI approach of Twitter.com
The main motivation of the new hybrid architecture was performance:
"That architecture broke new ground by offering a number of advantages over a more traditional approach, but it lacked support for various optimizations available only on the server"
- Any publicly loaded page is initially the same for users, logged in or not (maybe bots). This ends the dual model website for SEO support.
- It follows a Single Page Interface approach but avoiding hashbangs, instead the History API is used. History API is not available in older browsers with AJAX support like IE 6-8, in these minority browsers is accepted that user navigation is poorly paged.
Well, a lot, considering that there is a trend towards 100% client-centric applications accessing the server via REST APIs returning JSON data. Therefore, don't throw away your old web framework, especially your template processor, maybe you're going to need it again :)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)