Last month, half a billion people used a Facebook app. Next month, about 7,000 new apps will be deployed.
The apps out there today include Mafia Wars and Pet Society, Living Social and Texas Hold 'Em, FarmVille and Café World. The companies that have deployed these apps are raking in mind-numbing revenues, and the people who use them aren't giving them up anytime soon. (Check out the Facebook Application Directory.)
Want to be the author of one of next month's 7000 new apps? There are a few things you will need to understand, and this debut article of a series provides a high-level overview of the Facebook application development platform.
The Facebook Application Platform
Facebook's application platform is simple, both in concept and execution. At its highest, most abstract level, it is a client-server architecture with two distinct layers of presentation:
- The Facebook platform itself, which receives and redirects the call from the client
- An application server (chosen and implemented by you, the developer), which hosts the application itself
Any additional components in the application reside either inside that application server or somewhere behind it, again at the developer's discretion.
But the Facebook platform (whose internal architecture is transparent, for our purposes) isn't simply a high-powered router; in the pitch-and-catch between your client and application, Facebook can insert a great deal of familiar Facebook functionality, by way of APIs.
The social graph is the core concept around which Facebook applications are built. It is a hierarchy of objects that enable the Facebook social experience, starting with people and including things associated with them, like profiles and photos. Around these are environmental objects, including pages with which people are associated, events, and so on.
The Graph API
The objects of the Facebook social graph are created, accessed and managed within the context of the Graph API. This is the programmatic interface with the social graph and its object population, and its ease of use is something to behold. Every object in the social graph--every person, every page, every photo, etc.--has a unique ID, and can be directly accessed via the Graph API with nothing more than that ID (assuming you have the necessary credentials). When you see a username or a page name associated with a user or page, you're basically seeing an alias for that object ID.
Once you understand this key concept, the rest of the Facebook programming dynamic follows easily. If everything is an object, what follows is to create relationships between those objects--and that is the essence of Facebook, from top to bottom.
Within the Graph API, the next step in application development is the Facebook application design concept--Social Design, which encourages design that implements socially interactive leveraging of social graph objects to optimize identity, utility, and collaboration. (If this is all beginning to seem like an undergraduate sociology seminar, well, just settle in--you ain't seen nothing yet ... )
Programmatic manipulation of Graph API objects is conventional, with each object having fields for passing data, connections to other objects, and so on. Some objects can have their connections updated in real time. Objects are retrieved from and posted back to Facebook storage by means of HTTP
The list of Graph API objects is long enough to be mildly confusing, but makes categorical sense after brief examination: User, FriendList, Group; Photo, Album, Video, Note; Status message, thread; and so on. (We'll dig into some of these and play with them a bit in a later article.)
Facebook Application Code
That code lives on your application server, and is called from Facebook when a Facebook user invokes your app.
The Canvas Page