Review of Facebook app building experience and where things might go

I've been missing in action for a while, because during the first week of August, I finally got around to figuring out how to build a facebook app. I'm involved with a non-profit organization that wished to create an alumni database. I had written a prototype for them the year before in a week, but I never put it up. I didn't get the help or traction that I had hoped for, so I delayed working on it until this past summer, when they had another summer conference.

It's a good thing too, because facebook didn't release their full API until around May. The app is a good fit for what it needed to do, since it allows alumni to find each other. I hacked it out in 4 days, which was both good and bad. I had to bypass a lot of the discipline and good habits I cultivated on my own projects in order to whip it up.

The hardest thing about facebook apps is simply figuring out how the whole thing hangs together. When you don't know the thing is put together, filling out the long form to setup your facebook app, becomes difficult as nothing makes sense.

There are two major parts to a facebook app. One is a profile box, which is the draggable box you see in people's profiles. And the second is the canvas page, which is a kind of "home page" for your app, if you will. You application is hosted somewhere else outside of facebook. The API just lets you create an interface in facebook. It's my recommendation that you read this page on architecture in the facebook wiki before getting started on any of the "Getting Started" pages.

As you can see from the ASCII diagrams in the architecture page, your application's canvas page is called by proxy through facebook servers. That means every time someone visits your canvas page through facebook, facebook will pull your application's canvas page and display it. Conversely, the profile box is data that is pushed to the facebook servers. This makes sense in two faces of the same coin. Facebook has a LOT of users, and chances are, you can't scale as facebook has. Having lots of people bang on your server out the door would wreck havoc on you. Secondly, facebook doesn't want its profile load times to depend on 3rd party servers. If it has all the information pushed to it, facebook can quickly serve profile pages without having to rely on the latency of its 3rd party applications.

I won't go through how to make a facebook app. Plenty of places already do that well, especially this one for Ruby. However, to give my review, I will say that I give it 3 out of 5 stars. "A" for effort, but there's more improvement to be had down the line.

While the API is a step in the right direction, coding for it has felt clunky at best. This is mostly due to documentation being a bit all over the place, but especially the lack of a test environment. There is no way to set a production, test, or development environment for the same application. The only way is to simply create another application as a "test", and point it to your development machine. Then in your code, it has to switch between the development API key and the production API key. In Rails, you'd use the RAILS_ENV global variable to determine which environment you were in. As a result, there's quite a bit of setup to do before you can start hacking away.

Facebook also provides FBML, a reduced HTML, specific for facebook elements. Some of them are quite handy, such as a friend finder, and it gives you an immediate look and feel that blend in with the rest of facebook. However, debugging it isn't much fun at all. Since you can't set environments, facebook assumes all apps are production, and therefore will not show errors and stack traces. Therefore, one has to tread softly, or cut and paste back and forth to their tools.

That's right. Tools. Facebook does provide tools to test out your FBML and API calls. But it would be much nicer if it were integrated in a development environment for the application.

All, in all, it's not been too bad of an experience, outside of wrestling with the setup and FBML, but there's a lot of improvement to be had. While many have said that Facebook is a walled garden like AOL was in the 1990's, I currently don't see much of a decentralized social network solution that addresses privacy that is popular amongst developers.

The only thing that is a remotely good candidate is the combination of OpenID with Microformats like XFN. But I think it's going to take a demonstration from another successful startup to get more developers on this bandwagon. OpenID is also not yet ubiquitous as a concept in the minds of developers, let alone the common web user. Once this happens, it will be much much easier for social applications to personalize a user's experience right out of the box.

And this isn't personalization based on where your stats, but personalization based on what your other friends have done in the very same application. The web app won't know anything about where you live, or where your friends live, but if it's a book store, it will know everything about what books you like, and what books your friends like, and be able to draw conclusions to better serve your experience based on that.

I hope that is an indication of the things to come. Apps will know more about a user's habits as related to their function, and yet not know who this user is to protect privacy. This will be especially useful with mobile devices, since we carry them with us. Any mobile application that knows if you come into contact with your friends in real time will have a tremendous utility value in producing information useful in a social context. We still have to wait, however. The mobile industry is still not as open as we'd like for open development on mobile devices as a platform.

As an aside, I imagine that the reams of data (anonymous, of course) would be a great boon to social scientists. We might see a revolution in that field, especially if it's combined with decentralized computing concepts.