The Facebook developer documentation strongly encourages the use of FBML over IFrame for the outer application UI. They suggest that the FBML approach will be easier to build and have better performance.

So far all the Facebook development I have done has been FBML, and while I’ll agree that its fairly nice, it has some key drawbacks. First of all, if you have an existing site, you need to restructure it all in FBML. FBML is pretty close to HTML, but its hard to make any use of code-sharing between your “normal” site and the Facebook version (side note- sometimes this might be a good idea since often what works for Facebook will be different from what works with normal sites, but its still more work).

Also because you can’t use any script in the page, your ability to add javascript-based interactions to your page is very limited. There are some simple built-in Ajax functions, but they are simple enough that you often hit limitations.

On the other hand I don’t get the supposed advantages of FBML, especially the claim that it will result in better performance. How does routing all content from my server, through the Facebook ones, to be re-parsed actually improve performance? Sure, its one request vs. two, but my general sense is that Facebook is making tons of requests for the most simple things. Try hitting the refresh button sometime.

The first thing I did with an IFrame (using the IFrame embedded inside FBML approach) is to create a refreshing page. I created an ASPX page with the code-
Refresh.aspx-
<script>
window.setTimeout("top.location = '<%=Location %>';", <%=Timeout %>000);
</script>

Refresh.aspx.cs- (partial)

protected void Page_Load(object sender, EventArgs e)
{
Location = Request.UrlReferrer.ToString();
Timeout = Request.QueryString["r"];
}


The parent FBML page can then include this somewhere at the bottom to cause itself to refresh in RefreshRate seconds.

<fb:iframe frameborder="0" style="width:0px;height:0px;" src="http://www.fastcarrot.com/sinkmyships/refresh/<%=RefreshRate %>" />


Be careful when you do this to manage your refresh rate so you don’t destroy your servers. Its really easy for people to accidentally leave your page up in a tab unseen and if enough people do that your servers can be brought to their knees. My current approach is to have the server control the refresh rate so that it refreshes a couple of times quickly if you are interactive with the page and if you ignore it for a bit it slows down considerably. I suppose if I were smart I’d also keep a metric on the overall load on my server and automatically back off if the server ever gets pounded. For now I’m assuming that any growth curve (fingers crossed) won’t be so fast that I can’t go make a quick manual configuration update to have the refresh back off before it gets out of control.

This entry was posted on Monday, August 13th, 2007 at 9:04 pm and is filed under Facebook. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.