At the Forge - Integrating with Facebook Data

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

All of this seems pretty reasonable and straightforward, and it isn't hard to implement in any modern Web framework. But, if we want to implement the same functionality in a Facebook application, we have to consider that about half the database we just defined is going to be unnecessary. We don't need to worry about the Friends table, because that's something Facebook does quite well. And, we don't really need to worry about the People table either, as Facebook handles logins and authentication.

At the same time, we obviously can't use only the Friends table by itself. We need it to point to something, somewhere, so we can associate a visit with a user. How do we do that?

The answer is that instead of storing the users' information, we store their Facebook user IDs. Our People table, thus, will look like this:

CREATE TABLE People (
    id    SERIAL    NOT NULL,
    facebook_session_key    TEXT    NOT NULL,
    facebook_uid    TEXT    NOT NULL,

    PRIMARY KEY(id)
);

By storing the Facebook information in our database, we effectively hook our id column to what Facebook provides. But, how will we use this link?

The answer is that we don't really have to, if we use a plugin that handles the underlying details for us. I have used RFacebook for the past few months; this is a plugin for Ruby on Rails that makes it fairly easy to create a Facebook application using Rails. First, I create my models using the generate script that comes with Rails:

./script/generate model person facebook_session_key:string
↪facebook_uid:string

This creates a new model—that is, a Ruby class that represents a database table—called person.rb. Although this script doesn't create the model directly, it does create a migration file that defines our database table in Ruby:


class CreatePeople < ActiveRecord::Migration
  def self.up
    create_table :people do |t|
      t.column :facebook_session_key, :string
      t.column :facebook_uid, :string
    end
  end

  def self.down
    drop_table :people
  end
end

Assuming that our database is all set up, we can run the migration using the built-in rake tool (think make, but in Ruby):

rake db:migrate

The output tells us a bit of what's going on:

== CreatePeople: migrating ======================
-- create_table(:people)
NOTICE:  CREATE TABLE will create
    implicit sequence "people_id_seq" for serial column "people.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create
    implicit index "people_pkey" for table "people"
 -> 0.1939s
== CreatePeople: migrated (0.1944s) =============

The advantage of using rake and migrations is that we can modify our migrations file, change our database definitions, and move forward and backward in time through our database design. Migrations mean that you can keep track of your changes to the database and automatically upgrade (or downgrade) the database to the latest version without losing data. And, sure enough, if we look at our database, we see that it has three columns, just as we defined.

Next, we create another model for our visits table:

./script/generate model visit person_id:integer 
 ↪visited_at:timestamp

We migrate the database to the latest version:

rake db:migrate

And, sure enough, we have a visits table with a person_id column. Unfortunately, because Rails migrations are written in a generic language, there isn't any built-in support for handling foreign keys and other referential integrity checks. So, the table, as we defined it above, would have indicated that person_id always must point to a value.

Also note that the default model-generation script allows null values. We could go into the migration file and change this, but we will ignore it for now.

Mixing It Together

Now that we have a place for the Facebook information in our People table, we need to tell Rails to put it there. We do this by adding the line:

acts_as_facebook_user

in the model file, person.rb. By default, it will be almost empty, indicating that we will use ActiveRecord's defaults to work with our database table via Ruby:


class Person < ActiveRecord::Base
end

When we're done, our class will look like this:


class Person < ActiveRecord::Base
    acts_as_facebook_user
end

In our controller file (which I'm sneakily reusing from what we did last month, modifying the facebook method in the hello controller), I've modified the method to read:

def facebook
  render :text => "hi"
end

Because my application is called rmlljatf, I can go to the following URL: http://apps.facebook.com/rmlljatf/, and see my “hi” at the top of the page. After loading this page, I then look at my People table and find...that nothing has changed. After all, I told the system to create the table, but I didn't actually do anything with it! For that to happen, I need to use the built-in fbsession object, which gives me access to Facebook information. I then can say:

def facebook
  person = Person.find_or_create_by_facebook_session(fbsession)
  render :text => "hi"
end

And, sure enough, reloading the page creates a row in our People table.

Next, I modify my method to add a row to our visits table. I can do that with the following:

def facebook
  person = Person.find_or_create_by_facebook_session(fbsession)

  Visit.create(:person_id => person.id,
                      :visited_at => Time.now()).save!

  render :text => "hi"
end

Once I've modified the facebook method in this way, each visit to the site does indeed add another row to the visits table.

Now we should produce some output, indicating exactly how many visits the person has made to the site. For this, we create a view (facebook.rhtml), which can display things more easily:


<p>This is your <%= @number_of_visits.ordinalize %> visit.</p>

This short view displays the instance variable @number_of_visits and puts it into ordinal form, which is convenient. However, this means we need to set @number_of_visits in the facebook method. We do this by adding the following line:

@number_of_visits =
  ↪Visit.count(:conditions => ["person_id = ?", person.id])

In other words, we grab the current user's ID. We then use that ID, along with a built-in ActiveRecord value, to sum up the number of visits the user has made to the site.

Finally, it's time to introduce the Facebook magic. We know, from last month, that we can display the current user's Facebook friends without too much trouble; we use fbsession to grab a list of friends (and specific pieces of information about those friends), and then iterate over them, displaying them however we like.

Now, we do the same thing, but we also create a hash, @friends_visits, in which the key will be the Facebook user ID (uid), and the value will be the number of visits by that person. We give our hash a default value of 0, in case we try to retrieve a key that does not exist. We also use a bit of exception handling to ensure that we can handle null results. The final version of the facebook method looks like this:

def facebook
  person = Person.find_or_create_by_facebook_session(fbsession)
  Visit.create(:person_id => person.id,
               :visited_at => Time.now())

  # Count the number of visits
  @number_of_visits =
    Visit.count(:conditions => ["person_id = ?", person.id])

  @friend_uids = fbsession.friends_get.uid_list

  # Get info about friends from Facebook
  @friends_info =
    fbsession.users_getInfo(:uids => @friend_uids,
                            :fields => ["first_name", "last_name"])

  # Keep track of friend visits to the site
  @friends_visits = Hash.new(0)
  @friends_info.user_list.each do |userInfo|
    begin
      friend = Person.find_by_facebook_uid(userInfo.uid)

      @friends_visits[userInfo.uid] =
        Visit.count(:conditions => ["person_id = ?", friend.id])
    rescue
      next
    end
  end

end

In other words, we grab friend information via fbsession. We then iterate over each friend, getting its Facebook uid. With that UID—which we have in our People table, in the facebook_uid column—we can get the person's database ID, and then use that to find the person's number of visits.

With this in place, we can rewrite the view as follows to include friend information:


<p>This is your <%= @number_of_visits.ordinalize %> visit.</p>

<% @friends_info.user_list.each do |userInfo| %>
<ul>
      <li><fb:name uid="<%= userInfo.uid -%>" target="_blank" />
            <fb:profile-pic uid="<%= userInfo.uid -%>" linked="true" />
        <%= @friends_visits[userInfo.uid] %> visit(s)</li>
</ul>
<% end %>

Sure enough, when you visit the page, it tells you how many times you have visited, as well as how many times each friend has visited.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState