Two key tools for debugging things in Internet Explorer-

The IE Developer Toolbar

Fiddler HTTP web-proxy to let you see the real traffic. It even supports SSL.

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.

I’ve been developing some applications for Facebook lately. I got past the first couple of blocks fairly quickly and now have an application mostly working.

Of course there are always more issues. I expect many of these issues are typical for anything that is delivered as a service developer platform. The Amazon developer platforms are more back-end technology so its a bit easier for them to tackle some of these things.

The biggest issue so far is in general development process and staging. Since my application integrates with the Facebook UI and social features, its not entirely clear how to best manage those aspects. I usually maintain two copies of my web-sites, one that is the active public one and another private copy that I’m using for development and testing purposes. Actually there are usually 3- active development usually goes on using a local server on my workstation. The staging server typically doesn’t have anything that is especially secret, but it isn’t something that I’m worried about crashing/returning exceptions if something is not fully debugged.

With Facebook any site that working on needs to be something that can be accessed on the public Internet by their servers so the local developer-workstation test environment does not work at all.

So far I’ve managed without a seperate set of staging servers. Since my app is not yet open to the public, I don’t need to worry about breaking real users. But once I open the application up, I’ll need to deal with this. I assume I need to just register a second copy of the application with a different host header. The Facebook platform makes you use absolute URLs for everything which makes this a bit of a pain but I’m sure its something I can manage.

Since I can’t directly debug on my workstation as easily as normal (I could use remote debugging to the server but there are assorted reasons I don’t want to do that) I’ve had to rely on logging more for debugging. I’m using a “tail” utility for Windows that lets me display the log output in a window in real-time.

I’ve also signed up a second account to use as a test account to test the collaboration aspects. Of course this means I had to turn off the “developer mode” so the other account can access my application, and this in theory means that others could access the application. For now I just put in a server-side block so only those two accounts can get into it. Still, it wouldn’t be ideal if I really cared about stealth.

More on some techniques I’m using in the application itself soon. This platform is pretty new so there is only limited and scattered information about it around the web. I’ll try to collect some links here and post any tips I run across. I’m sure some of my suggestions will be wrong, but as usual I’m open to feedback and suggestions.