At the Forge - Integrating with Facebook Data

Writing a Facebook application means integrating your database with information kept on Facebook. Here's how you can combine the two quickly and easily.

For the past few months, we've been looking at the Facebook API,
which makes it possible to integrate third-party applications
into the popular social-networking site. Facebook is remarkable to
users for the number of people already using it, as well as for the rapid
pace at which new people are joining. But, it also is remarkable for
software developers, who suddenly have been given access to a large
number of users, into whose day-to-day Web experience they can add
their own applications.

The nature of Facebook means that most developers are writing
applications that are more frivolous than not. Thus, it's easy to find
name-that-celebrity games, extensions to built-in Facebook
functionality (such as, “SuperWall”) and various applications that ask
questions, match people together and so forth. I expect we
eventually will see some more serious applications created with the
Facebook API, but that depends on the developer
community. I would argue that the continued growth of Facebook
applications depends on the ability of developers to profit from their
work, but that is a business issue, rather than a technical one.

Regardless of what your application does, it probably will be quite
boring if you cannot keep track of information about your users.
This might strike you as strange—after all, if you are writing a
Facebook application, shouldn't Facebook take care of the storage
for you?

The answer is no. Although Facebook handles user authentication, gives
you the ability to deploy your application within the Facebook site
and even provides access to certain data about the currently
logged-in user, it does not store data on your behalf. This means
any data you want to store must be kept on your own server, in
your own database.

This month, I explain how to create a simple application on Facebook
that allows us to retrieve data from a user's Facebook
profile or from our local relational database seamlessly. The key to this
is the user's Facebook ID, which we will integrate into our own user
database. Retrieving information about our user, or about any of
their friends, will require a bit of thinking about where the
data is stored. However, you will soon see that mixing data from
different sources is not as difficult as it might sound at first, and
it can lead to far more interesting applications.

Creating the Application

Our application is going to be simple—a Facebook version of the
famous “Hello, world” program that is the first lesson in oh-so-many
books and classes. However, we'll add two simple twists: first, we
will display the number of times that the user has visited our
application to date. (So, on your fifth visit, you will be reminded
that this is your fifth visit.) Moreover, you will be told how many
times each of your friends has visited the site.

In a normal Web/database application, this would be quite
straightforward. First, we would define a database to keep track
of users, friends and visits. Then, we would write some code to keep
track of logins. Finally, we would create a page that displayed the
result of a join between the various pages to show when people had
last visited. For example, we could structure our database tables
like this:

Our first table, People, contains only a small number of columns,
probably fewer than you would want in a real system. We keep track of
the users' primary key (id), their e-mail addresses (which double as
their login) and their encrypted passwords.

We keep track of each visit someone makes to our site in a
separate table. We don't need to do this; it would be a bit easier
and faster to have a number_of_visits column in the People table
and then just increment that with each visit. But, keeping track of
each visit means we have more flexibility in the future, from
collecting usage statistics to stopping people from using our system
too much.

Finally, we indicate friendship in our Friends table. Keeping track
of friends is a slightly tricky business, because you want to assume
that if A is a friend to B, then B also is a friend to A. We could do
this, but it's easier in my book simply to enter two rows in the
database, one for each direction. To retrieve the friends of A, whose
ID is 1, we look in the Friends table for all of the values of
friend_id where person_id = 1.