O'Reilly logo

Facebook Cookbook by Jay Goldman

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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.

Facebook application architecture

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 being tied to something over which you have no control. Facebook has real momentum behind it now, so the risk is pretty low, but the Facebook team might also make a decision tomorrow about a new direction for Platform that could significantly affect the viability of your app. If you have no fallback strategy through other delivery channels, you have nothing.



[6] Thank you, Denis Leary.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required