Facebook's API and my old familiar

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Gerald Kanapathy's Blog | September 23, 2007   4:42 PM | Comments (0)

Facebook is hot. Like, so hot that if I were making a table of "hot" vs "not", it would include:

Okay, well, in the Bay Area Web 2.0 tech bubble world that is the case. In normal places, perhaps not so much. But hey, you can read something else if you don't care. I want to look at Facebook Apps. Or really, the Facebook API.

It seems there are over 4,000 Facebook Apps available, and there were over 1,000 in the first month. Now, most of them are completely useless stupid crap, but that is true of everything in the world, and it actually speaks well of the platform that it's so easy to use and deploy that even stupid useless applications manage to get created. And besides, there are actually are some useful and quality ones there.

What I found interesting was the similarity between the Facebook and ALUI mechanisms. No, I understate that. I was actually shocked at the similarities between the ALUI portlet configuration pages and the FB app configuration page, and between the plugin mechanisms.

At the most basic level, both of them work exactly the same way: When the FB/ALUI user goes to a page that displays the app, the platform/application makes a REST-style HTTP request to the (predefined) URL of the application, retrieves the content, runs it through some transformations, and displays it embedded in the FB/ALUI application. There are a few differences (e.g., ALUI has a greater selection of preferences pages, but FB has more end-user pages; ALUI has less restrictive HTML requirements, but FB provides more out-of-the-box transformer tags; ALUI sends more contextual data with the initial request, but FB makes it easier to get more on callbacks), but basically, they have the same architecture.

More than seven years ago, ALUI (then Plumtree) devised this remote portlet (then gadget)architecture for the portal to address a few problems we'd found with plug-in web app platforms, and now it looks like Facebook has decided on a similar solution. Why would both choose this?

Well, the more typical type of plug-in architecture is to run the plug-in/portlet/app directly inside of the platform. This is what other portals, Firefox plugins, Photoshop plugins all do. The problem with these is that because they run inside your application, they can cause your application to break. Most commonly it's just because of instability or poor performance, but potentially because of malice. You can deal with this in one of two ways:

• Test and certify and label apps, and inform people that they are taking risk if they install uncertified plugins
• Isolate the plugins so they can't damage the platform

Testing and certification doesn't really solve the problem, though. All it does is make the certifier liable in some way for bad plugins. It also discourages people from creating applications, and scares people away from using them, and requires you to set up some kind of certification bureaucracy.

Isolation it is then. In fact, the best isolation was not running the plugin at all, but making the plugin/portlet/app developer run it themselves. FB/ALUI would just take the final output from the plugin and include it. It happened that back in 2000, we thought that HTTP was a great mechanism for this, because it's no big deal for someone to run a web application on their own. (Back then, we didn't know it would end up being called REST, but there you go, we accidentally built a REST-style plugin architecture.)

This brought a lot of attendant benefits as well:

• Platform-independence: You can write your portlets/applications on any web platform, even without official support from the platform owner. For example, ALUI officially supports Java and .NET, and FB supports Java and PHP. But third parties have developed, for instance, Perl and ColdFusion libraries.
• Lots of portlets/applications: Because the isolation of plugins from the main platform is so effective, you don't need a lot of monitoring and control over people developing portlets/applications. So you can allow anybody to do it, which means lot of them get done. At the same time, if they do a bad job, they can't hurt the platform.
• Security: We ran on top of HTTP, so we could just use SSL for no additional effort
• Sessions: While in 2000, believe it or not, some people were still disputing whether cookies should be used to maintain sessions, we didn't worry about it. We just stuck with HTTP as she was implemented, and the solution came to us for free. (Mostly. In the early days we had questions about their scope.)
• Network flexibility: We didn't have to worry a lot about firewalls. And because HTTP was pretty good over long-distance networks, we rarely had to worry about network latency due to protocol chatter.

Anyway, we're continuing with a good idea. As I just barely alluded to in my last post, Ensemble continues to use a similar architecture for pulling in content to get mashed up.

Comments