Washington Post and Facebook Platform Development

A little over a week ago, my group at WPNI was involved in developing an application for Facebook's latest version of their platform. If you haven't yet heard about this, Facebook Platform now lets developers create full blown Facebook applications just like Facebook's own Photos, Events, and Notes applications. Any developer can create any kind of application which can run on Facebook itself. Our first application is called The Compass. (You must be a Facebook user to view or use the app.)

Rob does a much better job than I ever could of explaining the ideas, the creative process, and the Compass itself. I thought I would try to add a little on the technical aspects of the app, specifically the Facebook/washingtonpost.com intergration, deploying on Django, and server performance issues from the Facebook traffic.

Facebook Platform

Facebook has had a developer's API since late last year. This API allowed developers outside of Facebook a way to create web or desktop applications that could integrate data from Facebook's social network. A Facebook user could go to a website I created, and given the proper Facebook credentials, login to my site and have some or all of their social data from Facebook follow them. For example, their list of friends, groups, event information, and so on.

The current, updated version of this API contains all the methods that existed before --


facebook.auth.getSession
facebook.friends.get
facebook.groups.get
facebook.evets.get
  

but also, there are new methods specific to loading an app within the context of Facebook itself --


facebook.feed.publishStoryToUser
facebook.feed.publishActionOfUser
facebook.profile.setFBML
facebook.profile.getFBML
  

The latter methods are the hooks for publishing to a section on the user's profile. Calling those methods (through the Facebook client library of your choice) would allow you to publish a string of FBML into the user's profile. FBML is where the new version of the Facebook platform gets interesting and begins to separate itself from other simple widget platforms.

FBML

FBML, or Facebook Markup Language, is essentially html (stripped of script and other potentially dangerous tags) with a few Facebook specific tags. These fb tags allow the developer to access a Facebook user's data in a generic fashion. The real advantage of this approach is that with just the UID of a Facebook user, I can load related data in a Facebook page or on the user's profile without having to do any processing on my end.

For example, this --


{% for friend in friends %}
    <fb:profile-pic uid="{{ friend }}" />
    <fb:userlink uid="{{ friend }}">
      <fb:name uid="{{ friend }}" useyou="false" />
    </fb:userlink>
{% endfor %}
  

is an example in Django template syntax using FBML that would produce the following --

Facebook renders the FBML tags for you, which has some significant advantages. The user's profile picture is always set to the current profile pic just to throw out the most obvious.

Note: in the code example above, "friends" is a list of Facebook UIDs returned by calling facebook.friends.get.

Python Client Libraries

Everything we do at WPNI uses the Django web framework. Being a Python framework, this means everything we do is written in Python (short of several shell scripts for updating code, managing deploying, etc.). The initial example library that we received from Facebook was written in PHP. There was an existing Python version of the Facebook API hosted on Google Code, but it didn't have the new methods mentioned above nor did it seem to work all that well for me. So to get started with Facebook, I had to rewrite that PHP client library in Python. I did borrow a couple methods from the original Python library, but mine is largely a one to one copy of the current PHP library hosted from the Facebook developers page.

Since I was under a bit of a deadline pressure, I didn't port every method or else I would release my version. I did notice that the current Python library on Google Code has been updated. I haven't tried it to see if it works any better. I had hoped to spend a little time after our application's launch to finish out this library and do a little more Facebook development, but other deadlines are pressing down on our team. It looks like I may not get back to this, but if that changes, I'll post here with new info. If I ever have the chance to finish out the library, I'll certainly make it public.

To be continued....

Okay, this got to be a longer post than I first imagined it would be. I'll break this into sections. In a day or two, I'll post on how the Facebook/Django intergration actually works, and a day or two after that, I'll post on the server issues we experienced and offer some performance tips for scaling a mod_python/Postgresql application.

Posted by deryck on June 3, 2007

Comments

Ben on June 19, 2007 at 5:42 p.m.

This is very cool... I'd love to hear about the follow-up, when you get a chance. (I'm a fellow Django developer thinking about making a Facebook app, and I'm wondering about performance/scaling issues).

deryck on June 19, 2007 at 9:30 p.m.

@Ben

The scaling post is on the way. We're ramping up on another project at work currently, which has sidelined my personal work for the last week. I should get the time late this week or the weekend to finish it up.

Samuel Cormier-Iijima on June 21, 2007 at 8:33 p.m.

Hi,

I'm the author of the PyFacebook library. Since the F8 launch, I've been more interested in the website-side of development, and so of course I'm using Django :-). I've added a bunch of Django integration to the library, as well as cleaning up and fixing bugs. I'm interested in hearing about what you've added, and if possible combining our efforts (you're probably much more Django-savvy than I am). Some new things include Python decorators like @facebook.require_login() for Django views, along with FacebookMiddleware. Thanks a lot!

deryck on June 23, 2007 at 10:09 p.m.

Hi, Samuel.

I saw on another blog (maybe Jeff Croft's) that PyFacebook had been updated with some nice Django integration. In fact, another developer on my team was looking at it and suggested we use it now, given all that had been added to it. I'll certainly take a look in the next few days and see if we have anything to share back.

Post a comment