Building an app is a lot like building a house: poor architecture and foundations will only lead to a rickety structure that falls over the first time the big bad wolf blows on it (and by “big bad wolf,” I mean 100,000 users). Knowledge is power, so arm yourself with a thorough understanding of the way Facebook applications are structured, as well as some practical techniques for optimizing your app’s underpinnings.
Once you have the basics down, bring out the best in your awesome framework by adding a beautiful and functional design. If you’re more of a developer than a designer, don’t make the classic mistake of applying lipstick to your pig: good user experience design is much deeper than a pretty skin.
Most of this chapter is aimed at web developers who are building web-based Facebook apps, but a lot of the lessons in here can be abstracted to desktop apps as well.
Facebook Platform architecture is brilliant from its perspective: you go and do all the hard work of building apps, and you have to pay for the hosting, too. The upside is, of course, that you get unparalleled access to a dedicated audience of 90 million users and the ease of building on a fairly mature and well-realized Platform.
The short solution is: yes, you host your app. You’ll need to find a robust hosting provider who can scale up quickly if things go your way and who won’t charge you an exorbitant fee if you exceed your allocated traffic (see Hosting for more information about hosting choices).
Let’s take a look at what happens when someone requests a page from your app (Figure 4-1).
The user’s browser requests http://apps.facebook.com/myapp.
That address points to a cluster of servers in Facebook’s data center. Their servers analyze the request, determine which app it’s for, then look up the callback URL that the app developer provided and make a call to it behind the scenes.
Facebook server requests http://www.myserver.com/index.php.
This call, which happens behind the scenes and is invisible to the user, goes into your application server. If you’re hosted with Joyent or Amazon, you can take advantage of especially low latency rates, which speed this part of the process up considerably.
Your application server makes API calls to the Facebook Server as required by your page.
This can, of course, include FQL calls made through the API’s
fql.query()method. You may not need to do any calls, or you may need to do lots, but keep in mind that the user is waiting for his page while you do all this back and forth, so it’s better to try and cache as much data on your server as possible.
Your application server returns FBML to the Facebook server.
The end result of your app doing its thing should be an FBML document, which you’ll send back to Facebook’s server for processing.
Facebook’s FBML parser turns your FBML into HTML and serves it to the user.
This is the final step in the process and results in the browser rendering what appears to be a single Facebook page, made up of Facebook’s HTML code around the edges with your parsed FBML in the middle.
This is a really clever piece of system design and makes for a lot of flexibility, but it also has some obvious spots where a slow network connection or poor page implementation can result in very slow page loads for your users. If you’ve ever run into a timeout error when you’re trying to use a Facebook app, one of the five steps just outlined has probably taken too long. You can see it for yourself by inserting:
into one of your PHP files and then requesting that page through Facebook.