Beautiful Architecture

Creating a Social Data Query Service

We have expanded our internal libraries to the outside world by creating a web service with a user-controlled authentication handshake. With this simple change, Facebook’s social data now drives any other application stack its users choose to authorize, creating new relations within that application’s data through a universally interesting social context.

As seamless as this data exchange becomes in the mind of the user, the developer consuming these platform APIs knows the data sets are very distinct. The pattern the developer uses to access his own data is quite different than the one used to get Facebook’s. For one, Facebook’s data lives on the other side of an HTTP request, and making these method calls across many HTTP connections adds latency and overhead to the developer’s own pages. His own database also offers a higher granularity of access than do the few dozen methods in the Facebook Platform API. Using his own data and a familiar query language such as SQL allows him to select only certain fields of a table, sort or limit results, match on alternative indices, or nest queries. If the platform’s API does not offer the developer the ability to do intelligent processing on the platform’s server, the developer must often import a superset of the relevant data and then do these standard logical transforms on his own servers after receiving it. This can be a significant burden.

product problem: Obtaining data from the Facebook Platform APIs ...