Facebook Cookbook - Jay Goldman [35]
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:
sleep(120);
into one of your PHP files and then requesting that page through Facebook.
Architecting for the Future: Open Web Apps
Problem
I’m following your advice and building for Facebook first, but I want to make sure that my app can be deployed elsewhere later. What steps should I take?
Solution
You should build one backend that is capable of serving your application’s core data to several frontends, as shown in Figure 4-2.
Figure 4-2. Facebook application architecture
Layered architecture diagrams always make me think of tasty cakes. This particular diagram makes me think of a tasty cake that comes in four excellent flavors but doesn’t cost the baker much more in baking time. It also makes me think of Mark Andreessen, founder of Netscape and now of OpenSocial partner Ning. If you read the Preface, this probably comes as no surprise. If you didn’t, you might find yourself grasping for a connection between a brilliant serial entrepreneur and baked goods. Look no further than this quote:
As an app developer, there’s no real reason to choose between Facebook and OpenSocial. It’s easy to do both. You’ve already put in most of the effort—creating a new set of frontend HTML and JavaScript pages is almost trivial, and that’s all you need to do to have your app “port” to OpenSocial.
As you start planning your application, think about ways in which you can consolidate your business logic, backend code, and data so that your application server is fairly independent of the particular API you need to use to render a page. Although the calls required to display a friend selector, for example, won’t be the exact same on Facebook Platform as they are on OpenSocial, the data returned to your application will still be a selection of friends.
Discussion
There’s a term that gets thrown around a lot in web development circles that always makes my sub-cockles[6] itchy: future proof. The idea that we can design something today that will be able to withstand whatever the future may throw at it is to give ourselves far too much credit. (Unless you’re Danny Hillis, of course. Danny can give himself that much credit because he deserves it: anyone determined to build a clock that will last for 10,000 years on a hill in the Nevada desert gets pretty much all of my respect. See http://www.longnow.org/projects/clock/.)
At any rate, you don’t need your application to last for 10,000 years, but you do want to try to see around the next curve in the road. There was a time, not too long ago, when everyone thought that Friendster was the best thing since Sir Tim Berners-Lee invented sliced bread, but now it’s a relic of the past. If it had introduced a developer platform back when it was the flavor of the month, we might all still be Friendstering instead of Facebooking.
Following an architecture like the one described earlier frees you from