Reprinted from my Skyway Community Tech Blog posting:

As I was familiarizing myself with Facebook, I scoured the web for information relating to the deployment of Facebook applications.  One of the first articles that I read indicated that Facebook applications must be hosted on a public server to be integrated with Facebook.  While this generally makes sense for acceptance testing and or production instances of an application, the article also indicated (or at least led me to believe) that you had to do this for development as well.

This of course was a bit troubling to me because I’m accustomed to working in a rapid build/deploy environment.  I like to make incremental changes to my application and deploy to my local server to see the results.  This process must be easy and very fast.  I don’t want to be waiting for my application to be compiled, deployed and initialized, and ideally the whole process takes less than a minute.  It would be extremely annoying if after every change to my Facebook application I would have to push my application to my host provider, just to see it running within Facebook.

Well it turns out that my concerns were only partially true.  Going back to what I covered in post #2 (Overview of Facebook Application Development), there are two options for integrating your application: FBML and IFRAME.

If you select FBML, your application is proxied through Facebook servers.  Essentially Facebook servers are making calls to your application.  In order for Facebook Servers to reach your application, your application must be hosted on publicly accessible server.  As you may recall from the previous post, I decided not to use FBML.  This deployment requirement is one of the reasons why I decided against the FBML option.

On the other hand, the IFRAME option doesn’t have the same problem.  IFRAME applications aren’t proxied by Facebook.  Instead they are embedded into the Facebook UI using an IFRAME, which makes an independent call from the end-user’s browser to your application.  It bypasses Facebook altogether.  In my opinion this approach is more ideal.

So when using the IFRAME option the only difference between a development environment and a production environment is the Callback URL.  In a production environment the Callback URL points to your public host provider (www.myhost.com).  In a development environment the Callback URL is pointing to your local workstation (localhost).  As you access your Facebook application (through Facebook) from your workstation, the Callback URL will point to the Facebook application running on your workstation.

So here’s the summary of my Facebook development environment:

  1. Eclipse + Skyway Builder CE
  2. Apache Tomcat 6.0
  3. MySQL 5.0

I have registered a new application in Facebook using the Developer application.  The Callback URL is pointing to the application that I created and deployed locally.  But wait…I haven’t covered creation and deployment of the Facebook application yet.  I guess I’ll cover that in the next post.

This post is one of a series of posts relating to developing Spring-based Facebook applications using Skyway Builder: