At the Forge - Working with Facebook

Web sites have become increasingly sophisticated during the past few years, providing a wide variety of applications to the public at large. Many popular sites now offer a variety of APIs, making it possible to interact with the sites, or just retrieve data, from within a program other than an interactive Web browser.

One of the most sophisticated and popular APIs to be unveiled in recent months is from Facebook. Facebook, as you probably have heard, was started by Mark Zuckerberg when he was a student at Harvard. He has since dropped out of college and has led Facebook to be one of the largest and best-known social-networking Web sites, offering people a chance to find and connect with friends and individuals with similar interests.

Facebook has become enormously popular in the last few years, particularly among US university students. But in mid-2007, Facebook unveiled an API that was far beyond what most other sites were doing. This API did not make it particularly easy to retrieve data from Facebook or to perform searches against its extremely large database. Rather, it was designed to let individual developers create new applications that could fit into Facebook's existing site.

If the first few months are any indication, Facebook's application platform has been a wild success. According to a report published by O'Reilly Radar in October 2007, more than 4,000 applications for Facebook have been released since the platform was first unveiled. Some applications have become staggeringly popular; the report estimates that these applications get more than 30 million page views per day, which works out to more than 2% of all Facebook page views.

Other social-networking sites have realized that they must respond in kind. Both LinkedIn and MySpace are (at the time of this writing) working on APIs of their own. But, it remains to be seen if their APIs will provide the deep integration that Facebook is offering. Granted, not every Facebook application is good, and many of them are getting far fewer than the millions of users enjoyed by the top tier.

Whether Facebook turns out to prevail in the social-networking wars is an interesting topic to debate, and it is being discussed at length by business reporters and those interested in what's known as Web 2.0. What's more interesting to us, as Web/database developers, is the fact that Facebook has provided programmers with an enormous opportunity, making it possible for us to add our own applications to their site.

Last month, we created a simple “Hello, world” application that lived on our own server and was powered by Ruby on Rails. But, this application wasn't designed to be served up on its own. Rather, it is meant to be invoked via Facebook. When people go to the URL http://apps.facebook.com/rmlljatf, they will stay on Facebook, with the look and feel of the page remaining that of Facebook. But the contents of that page—currently, nothing more than “Hello from Facebook”—are generated dynamically by a Rails application sitting on my server, atf.lerner.co.il. Think of Facebook as a giant, smart proxy server, transparently passing certain HTTP requests to my server whenever someone tries my application.

This month, I explain how Facebook lets us do much more than display “Hello, world” messages. I show how we can retrieve and display information from Facebook and take an initial look at how we can use Facebook's FBML markup languages.

I also continue to develop the application I created last month—named rmlljatf—which I created using the Ruby on Rails framework in general and the RFacebook plugin for Rails in particular. See Resources for information on where to obtain this software.

Last month, we saw how we could create a very simple “Hello, world” application using Ruby on Rails and RFacebook. However, it's not that exciting to produce such output. For example, how do we know that the person is really logged in to Facebook? (Beyond the fact that the page is rendered under the apps.facebook.com hostname and has the look and feel of the Facebook page, that is.) And, where are all the nifty, cool Facebook features we have come to expect, which we would expect to use from within a Facebook application?

If this were a normal Web/database application, we simply would create an SQL query, retrieve information about the current user from the database and display it. For example, if we were interested in retrieving a list of the current user's friends, we would write something like this:

SELECT F.friend_two_id, P.first_name, P.last_name
  FROM Friends F, People P
WHERE F.friend_one_id = 123
    AND F.friend_two_id = P.id

The above, of course, assumes that we have two tables. The first table is named People, in which each person has an ID, a first name and a last name. The second table is named Friends, and it indicates who is friends with whom; each friendship is indicated with the friend_one_id and friend_two_id columns, each of which is a foreign key to People.id. Modeling friends in this way requires two rows for each friendship. This might not be the best way to keep track of links, but it reduces the complexity of the logic in SQL queries.

If we were using a straight Rails application, we could eliminate the SQL altogether, relying on the automatic way in which Rails retrieves such data. For example, we could say:

@friends = @person.friends

This automatically would fire off an SQL query not unlike the one we saw above, albeit behind the scenes. The advantage is not only that we get to write (and read and debug) less code, but also that we can think at a higher level of abstraction, looking at our users in terms of people and links, rather than rows, columns and tables.

Either of these techniques would work fine with Facebook, except for one little problem: we don't have access to the database. Rather, we have to ask Facebook for data, authenticating ourselves as a particular user within a particular application. Only after we have told Facebook who we are can we gain access to the data. Moreover, Facebook makes it easy for users to share only particular pieces of information with third-party applications (and other users), so you cannot be sure you will have access to everything.