Facebook as a platform, pt2

I thought that it might be useful to blog my experiences with the new Facebook Platform API. For the past two weeks I've been working on Bookshare in my spare time. Bookshare is a book review site with social networking features (feel free to sign up and let me know what you think).

Anyway....

Facebook makes you think about scalability

Here was my first harsh Facebook lesson: apps can spread fast. Not necessarily exponentially but always faster than you can iterate over your code optimizing it. Quick hacks come back to bite you in the ass hours after you implement them, rather than months, because your userbase can double overnight.

Here's a fictional but in no way implausible scenario: imagine that you wrote an application that shows lolcats on people's profile pages to try out the Facebook API. You make the app public and then forget about it. A week later it has 1.7 million users.

A good problem to have? Maybe. Until you get your bandwidth bill (not a problem for images, luckily, as Facebook caches them locally, but still) or you want to use your server for anything else... ever.

Usually if your site slowed down a bit you'd be OK, but unfortunately:

Facebook times out. A lot.

If you visit

http://apps.facebook.com/bookshare/dashboard.php

then Facebook fetches the output of dashboard.php from my server and renders it inside of the Facebook page template (containing the Facebook logo, sidebars, footer etc.).

The problem is that there is an awfully short timeout on the Facebook server fetching remote pages. If your site is being slower than usual (because of an unoptimized SQL query, perhaps?) then this is reflected on Facebook by all of your application's canvas pages being totally unavailable - they get replaced with a non customizable 'could not retrieve page, try again in a couple of days' type error. A couple of days? Way to drive off users. What's wrong with suggesting that they hit 'reload' instead?

Imagine getting 1.7 million messages of complaint from angry lolcatters who can't access your app any more.

Official support is a bit lacking

I can kind of understand this as they've presumably been inundated by requests and bug reports, but for a company that's done right by developers in so many other respects their direct support sucks. I emailed off a report about a specific bug and got back an intensely annoying 'thanks for trying the Facebook Platform, all the documentation you need to get started can be found online' form letter reply.

The documentation was written by developers

The official client library is in PHP (as is the UI of Facebook itself). Unfortunately the online documentation only ever refers to the underlying REST calls to the server, so you have to actually delve into the code to see what the naming conventions are.

Despite all this, it's brilliant

You don't have to worry about persuading users to come visit. You don't have to write login or session handlers. Or friends lists. Or a messaging system. Your images get cached. The audience is large. The API is well designed.

I think they're on to a winner.