Beautiful Architecture - Data grows up

Chapter six of the Beautiful Architecture book presents the architecture of the APIs that Facebook presents to external third-party applications. It is written by an engineering manager at Facebook, but one would almost suspect that it was written by a product manager as it is written to sell a service. It reads almost like a tutorial presenting different services, the ideas behind them and examples of their use.

The main idea is that data is key and that other applications besides Facebook can benefit from the social relationship data contained in its databases. These applications need not have social interaction management as their core services, but can be anything that can benefit from this type of information to enhance how they present their own data to their users. The chapter's argument is that Facebook already have this data so why should every other application need to build it from scratch? Some time ago I heard about the vision of Facebook as the core platform of the social internet in the same way that Windows has been the central platform of the personal computer. The APIs presented in this chapter ties directly into this vision, providing services as well as a full platform for augmenting application domain-specific data with Facebook's.

It is divided in four main sections. The first two present data retrieval services that facebook provides, namely their data retrieval web services and their data query language FQL. The former allows the user to retrieve small sets of data while the latter allows the user to retrieve larger data structures in one call. The rationale for the second is to reduce the latency incurred by remote calls across the Internet by allowing such calls to be conglomerated as well as to move the burden of query logic to the FB servers. In a recent tech talk by Google that I attended one of the speakers gave a very interesting talk about latency pointing it out as the enemy of user experience. Their empirical studies showed that 158 ms is the upper limit to what we perceive as instantaneous. Furthermore the round-trip latency of one http call across the continent can easily consumes one fifth or more of instantaneous. This is a fundamental property that is due to the "limited" speed of light and latency in routing mechanisms and that means that the budget of instantaneous doesn't allow for many such calls!

Their web service APIs (RPC and FQL) are obvious ways of exposing their data though, even though the discussion on security and authentication challenges were fairly interesting. What I found much more groundbreaking however was the services described in the later sections. These services, mainly the Facebook Markup Language (FBML), FB Java Scripts (FBJS) and FB cookies turns the previous model on its head. Instead of Facebook providing a set of services that allows the third party applications to query social data the applications themselves become the services providing information to the Facebook platform. Facebook adopts the role of the web browser from the applications' point of view and they in turn provide FB with markup information and data from their own databases. FB will then process this markup language providing data from its databases as needed and forward it to the end user's browser as HTML, etc. In addition FB allows the applications to provide limited declarative scripts that FB turns into Javascripts.

The whole concept of Facebook as a browser is quite interesting, although I find it humorous how it follows the adage of "solving every problem by adding yet another level of indirection". In addition they have reached the conclusion that imperative, turing-complete language such as JS poses too much of a security risk to allow into their system outside the (somewhat) protected environment of the web browser. Instead they provide declarative languages (FBML and FBJS) that they in turn turn into the necessary standards accepted by the browsers. Like all declarative languages these languages require the developer to say what she wants instead of how she wants it. This means it is easier for the compilers inside the FB platform to guarantee that the code is safe by design as it has more semantic information.