Chicken Scratches

Making a Facebook app (with Django) – part 1: The Perils

Facebook made a splash a year or two ago when they opened up their API. Now developers could write applications that integrate with the site. Instantly, users — many of whom had fled to Facebook from a spam-filled MySpace — were inundated with Requests to battle ninjas and News Items bearing obscene pictures. To Facebook’s credit, they did clamp down and put some restrictions on what apps can do. A few entertaining or useful applications have risen to the top, and the potential of the API is ready to be exploited. It’s not an easy task for a developer, however.

In the next few Chicken Scratches posts, I’ll talk about my experience developing two Facebook apps from scratch: The Limerick Book, a site that works both in and outside of Facebook and allows users to share and rate Limericks, and Play Scopa, a traditional Italian card game that users can play against each other in realtime (this one is not yet launched to the public).

This first post discusses some of the difficulties I have run into. In the next couple posts, I’ll discuss how I dealt with them. First, to set the scene:

My setup

I am using the Django web framework for my backend development, the latest SVN version running with Python version 2.4 on a shared host at Dreamhost. In fact, it’s the same server I use for this site and weblog. To connect Django to Facebook, I am using the nice PyFacebook library, which is pretty mature, though I had to modify the code to support some of the latest features of the Facebook API.

And now, on to the perils.

Peril 1: Birds of a Feather

The first peril I ran into is just what I described in this post’s introduction: there are a lot of really crappy Facebook apps out there, and there is a very real danger of the product I worked so hard on being associated with all kinds of toy apps, spammy apps, buggy apps, or just poorly designed apps. This is similar to what it was like programming in JavaScript in its early days: nobody thought anyone could do “serious” programming in it. Luckily, Google changed all that with their Maps. The Facebook platform is still struggling with this stigma. Unfortunately, it is a fairly well deserved stigma, as you can see by browsing the Developers Forum archives. There are a lot of amateur or inexperienced developers who think, “hey, that looks cool. I wanna write an app.” It’s tough to find anyone on the forum who can answer a legitimate question, and hard to find the answers through all the noise.

Peril 2: Layers of indirection

Debugging can be very difficult. The major added difficulty in debugging a Facebook app is simply that the app has to run on Facebook. In typical web development, you can usually edit and test right on your local machine, or at least on your local network. I have come up with some tricks, which I will document in future posts, to enable as much local testing as possible, but much of your time will be spent debugging interactions between users, between your app and users, and between your app and the Facebook platform. This requires a tedious cycle of edit, upload, test; edit, upload, test; edituploadtest edituploadtestedituploadtest, and so on.

Developing client-side scripting is especially difficult. You need to write in a limited variant of JavaScript, called FBJS, which is translated dynamically to JavaScript, but with all kinds of name-mangling and pre-processing, so line numbers don’t match up and all variable names are prepended with a whole bunch of cruft. If you think Internet Explorer’s error messages are cryptic now, you ain’t seen nothing yet!

Peril 3: You’re at their mercy

The Facebook API is still pretty new, and Facebook itself is still a young company. There are inevitably going to be growing pains, and in fact, as I write this, Facebook’s backend servers are experiencing some major network issues, causing many apps to not function properly. It can certainly be frustrating not knowing whether something is failing due to a local bug or a problem with the API.

In addition, APIs, policies, and presentation are constantly changing. Can I post a profile message today? Can I send an email? To which users? Better check the rules, because they’ve probably changed. It is of course Facebook’s playground, so it is their right to change the rules as much as they want, and we as developers just have to be ready to deal with that. It’s a fact of life, and it’s another unique challenge of developing a Facebook app.

Peril 4: It’s different

Anybody who has developed web software for any length of time has built up a library of reusable “stuff:” page templates, JavaScript libraries, development patterns. Unfortunately, many of these things are useless when developing for Facebook. The markup language, FBML, is almost, but not quite, HTML. The front-end scripting language, FBJS, is almost, but not quite, JavaScript, and so on. It requires re-learning or re-implementing a lot of the standard tips and tricks.

But I’m doing it anyway

Well, what can I say? Developing for Facebook is fun. It’s very visual, and it’s rewarding to share what you’ve created with your online “friends.” Stay tuned for more posts on my development experience, including some of the more technical issues and how I dealt with them, using Python and Django.

Track comments by RSS

2 responses to “Making a Facebook app (with Django) – part 1: The Perils”

  1. Josh says:

    Hi there, I noticed that you used dreamhost for hosting, and the django framework. Been trying to figure out the pyfacebook stuff. But can’t seem to get the middleware to work. I’m guessing that you either had that problem, or have heard of it. I’ve been trying to find a workable solution for quite a while, have tried a few tutorials, but can’t for the life of me get it working. Was wondering if you could help or point me in a direction that I might find the solution.


  2. Hi Josh.
    What specific problem are you seeing? (Check your logs for error messages, etc.) One thing to note is that the pyFacebook REST code is very old, in Facebook-time, and FB is now recommending a different interface that they call the GraphAPI.