Question

Answer: Time to set your clocks ahead for Daylight Savings Time. *

Answer: Barbara Feldon’s birthday **

Answer: IFrame apps will be accessed through HTTP POST instead of GET.

That’s right kids, as Facebook has been telling us for some time now, your IFrame apps will be accessed from your customer’s clients by a POST instead of a GET. This is significant because it is most definitely a breaking change, e.g. one that has the potential to make your application stop working if you aren’t careful, so pay attention.

So why is Facebook doing this? Well, it has to do with a little something we call privacy. The problem is that a customer’s Facebook userid used to be passed in the URL (as part of a GET) so that the application could know which user a request was coming from. The problem is that subsequent calls would retain this userid in the HTTP Referrer header, and possibly allow third parties to get access to it. Privacy advocates rightfully have a problem with this, so Facebook looked for ways to fix the problem.

The solution to the problem is not to use a GET but rather a POST and pass the customer’s userid as a POST parameter. If all access happens over a secure channel (like Facebook now allows us to do) there’s no fear of exposing userids to third parties. Good solution, except for the fact that if your application expects a GET and receives a POST instead, you’re hosed.

So what to do if you have an IFrame application? Well, test it before Saturday comes lest things break. To do this, you must go into your application’s settings and enable the POST for Canvas selection.

Once this is done, Facebook will provide different HTML to the client’s browser so that your application is accessed through POST instead of GET. Be very careful though if your application is already live. If your application is broken by this change, then selecting this will effectively knock your app off of Facebook. So to be safe, register a test application and use that instead.

More technical information about this change can be found here. Facebook offers some simple solutions for how to do this migration on popular development platforms. There’s also some feedback from developers who’ve experienced some problems, so it’s a good place to start if you find problems yourself.

Good luck.

* Yeah, technically this happens on March 13, but better do it before you forget.

** We loves us some Agent 99 so much we won’t give away her age.

Facebook application development teams have always needed to register who was on the team with Facebook, so that those people could access, build, and test the application before it was released to the greater public. The problem was that belonging to the team was binary – you were either in or out, and only those that were in could access the pre-released app. However, all of the team members could view and modify the Application Secret, change the app’s URL, or throw everyone else on the team off. It didn’t matter what your actual job was, if you were on the list you had absolute authority.

The new Developer's Role dialog

Facebook has now changed that by allowing you to define the roles for the people on your dev team, and thereby limit what they can and can’t do. Here’s a list of the roles you can assign:

• Administrator – complete access to the application and all its settings
• Developer – can modify all technical settings and access Insights but cannot reset secret key, delete application, or add additional users
• Tester – can test the application in sandbox mode but cannot modify the application
• Insights User – can access Insights but cannot modify the application

This is great news, and is a step in the right direction to show that Facebook application development is growing up. I’ve done some consulting on testing Facebook apps, and have always been uneasy when I’ve been added as an applications “Developer”. I always felt uneasy about getting exposure and access to a company’s crown jewels, and asked to be taken off the list as soon as the gig was up. Now, I can be added as a “Tester” and gain access to only those priveleges that I need.

So let’s hope Facebook continues along this thread and provides more tools and services that acknowledge that Facebook application development is being done by teams that have real needs. For example, a real development team will want to stage any code changes before making them live (just like what Facebook does with the Beta Tier). Unfortunately, the only way to test this beta code is to register another application with Facebook so that the production and beta code can run in parallel. But registering a new application will cause a new Application ID/Secret to be created. This means that once the beta code is proven to be good it will have to be modified in order to be run as production. Bad bad idea, but it’s the only way that Facebook will let you do it. It would be nice if Facebook would provide some easy ways to deal with things like this, as well as other difficulties that large dev teams certainly encounter. Facebook – give me a call, I have lots of other ideas.

So what would you change to help your development team interact with the Facebook Platform more easily. Leave a comment to let us know.

Let’s contrast a Facebook app with a plain old Web Application. Imagine you’ve just finished designing and building your great new Web App. Before deployment you test every possible thing that could go wrong and you feel really confident about its stability and robustness. You’re so confident that it won’t break that you decide to relax and spend the next two weeks in Bora Bora without even a laptop. Things may go wrong, but if your app is really well-written, then all of the problems will be operational problems. Someone tripped over a power cord and knocked out a router, or spilled coffee into a server.  Things that are certainly problems, but they don’t need you the programmer to fix them. Go get yourself another drink and don’t worry about your app.

But Facebook development isn’t like that. You still need a good operations team to make sure your app stays online, but the stability and reliability of your Facebook app also depends on the invisible hand of Facebook, something that you have no control over. Before booking your flight to Bora Bora you’ll need to come to grips with the possibility that Facebook could very easily push out an update that changes an API in a way that breaks your application. If/when that happens to you, then you the programmer will need to do something about it to get your app back up and running again, even if it means getting up from the beach. And that’s the important point here: Facebook applications can and will experience regression even when they aren’t being changed because Facebook is always changing.

The first step to dealing with a problem like this is knowing that there is a problem. If you have a general Web App, knowing that it isn’t working isn’t so hard to do. You can simply set up a monitoring system to periodically hit the app and make sure that it responds properly. There are many inexpensive commercial services that make this really easy to do.

But what about Facebook applications? You can monitor the application to ensure it is up and running, but that won’t tell you if Facebook has done something to break it. That’s why Facebook’s Beta Tier is so valuable – you can find and fix potential problems before they get seen by users.

But how can we do this automatically? It would be great if we could set up an automated way to know that the next Facebook update will break your application. In our next post we’ll look at some strategies for how we can do this. In the meantime, leave a comment if you think this would be a good idea, and any thoughts you have about it.

That’s right. Have you ever thought about how Facebook tests its own product? Well wonder no more as the good people at Quora have already asked that question, and Steven Grimm, Facebook’s test engineering tech lead has provided quite a good answer.

A few interesting take-aways:

• For a company that’s so grounded in PHP, it’s interesting to see that they’re so heavily invested in Watir, a tool from the Ruby world.
• “Facebook has no dedicated QA team.” Now for many people, this will come as no surprise. For others from a more traditional development background, no dedicated QA for something as large and mission critical as Facebook seems like a really bad idea.
• They don’t talk about load testing. From what we can tell, they probably don’t even do it. In a lot of respects, a proper load test of Facebook is probably far more trouble than it’s worth.

Facebook Canvas applications

To understand why PLT is a bad idea for Canvas applications,  we must go back and understand the Canvas architecture. Users interact with Canvas applications by using a browser connected to the Facebook server which acts as a middleman and requests data from the app. The app may call APIs that interact with the Facebook server, and then ultimately return an FBML file to Facebook which renders it into HTML for return to the users bowser. The problem is that if we only look at PLT by measuring response time at the browser, we have all of this extra stuff being counted in the timing:

• Network latency between the browser and Facebook
• Time required by Facebook to figure out which application must be called, authenticating the request, etc.
• Time to render the FBML into HTML
• Time spent at the Facebook server servicing API calls

These “extraneous” functions will take an unpredictable amount of time depending on, among other things, the current load at the Facebook server. This will make it hard, if not impossible, to positively correlate the timings of two different test runs. Since one of the prime motivators of load testing is to see the effects of changes to the code on performance, metrics like these will ultimatly prove to be of little use.

Facebook Connect applications

Using PLT for Facebook Connect applications is a little bit better. Users interact with Facebook Connect applications directly, and do not need the Facebook server to act as the middleman. The only extraneous functionality being counted in the timing is the time spent at the Facebook Server responding to API calls. If there are many API calls being made, this will cause a bit of randomness in the metrics.

Application Response Times

In contrast to PLT, creating metrics based on the Application Response Time is much more meaningful and useful, although harder to calculate. Application Response Time should calculate the amount of time spent at the application and only the time spent at the application. Unfortunately, in contrast to PLT there’s no simple way to get the Application Response Time – you’ll need to do a little bit of work to get at it.

To calculate this, you’ll need to create a stopwatch function which starts when your application is called, and stops when the application completes the request and returns an FBML file to the caller. In between, the stopwatch needs to be paused when a Facebook API is called. Finally, those of you using PHP as your development platform should check out the microtime() function as it’s much more accurate than the standard time() function. If your application is able to keep up with all of the bookkeeping, you’ll have metrics that can accurately show you the effects on application performance from any changes you make.

For those of you who don’t want to be bothered with keeping track of all of these timing calculations, please note that FriendRunner does all of this for you automatically.

So why am I talking about this event on a place dedicated to testing Facebook apps? Simple, it’s because the most important thing taken out of Facebook to create the Lite version was applications. You can’t run applications on Facebook Lite (or more correctly you couldn’t run apps on Lite). One of the reasons that Lite failed was because users like apps. Apps are important.

Test your apps.

Calvin's dad on load testing

Load testing Facebook applications is really important. Usually the whole point of deploying onto Facebook is to leverage the social graph and go viral. Developers want their applications to go viral, but there’s a nagging concern about what will happen if they do. Is the app as scalable as you think? Are the hosting choices correct? What’s the cost of deploying and crashing?

The way to alleviate these concerns is to load test your app, but how do you do that in a Facebook environment? The simple answer is that it’s very hard due to two issues central to Facebook:

Issue1: You must control enough Facebook users

Testing your application with one or two simultaneous users is easy: simply use your own Facebook account and call up some friends and have them do the same. But running a test with hundreds or even thousands of simultaneous users is much more difficult. Where do you get the users from? That answer isn’t so simple. You can say “I’ll just go into Facebook and define a few hundred ‘phony’ people that I can control”. While this may seem like a good idea, it isn’t:

• It violates the Facebook Terms of Use (section 4.1) which prohibits you from creating phony accounts. When Facebook finds your phony account, they will delete it.
• Real users have friends, become fans of pages, post updates, and hundreds of other things that Facebook allows you to do. This creates the richness of the social graph, and applications often need to take these things into account. Unless you’re willing to spend an inordinate amount of time “humanizing” your phony user army, your tests with them will not be realistic.
• While Facebook does provide the concept of a Test Account to developers to test with, these accounts are very limited in what they can do so are not of very much use for load testing.

Issue 2: Load testing must be automated

Load testing web applications is hard. Traditionally, to test an application you’d deploy it into a “staging area” and then simulate many people using it with a tool such as HP’s LoadRunner or a cloud-based solution such as BrowserMob.

Load testing by it’s very nature must be an automated process. But this is a problem since Facebook applications must be accessed through the Facebook servers (for API support, FBML-to-HTML rendering, etc.)

Load testing the traditional way

This is a problem because it violates Facebook’s Terms of Use (section 3.2) which prohibits the use of accessing the Facebook servers with automated tools. This will force us to rethink our Facebook application load testing strategy.

In Part 2 of article, we’ll discuss why Facebook has a prohibition against automated tools, and why that is ultimately good for you, the developer.

You may be wondering… since Facebook apps are Web apps, why do I need a special place to discuss testing them? Can’t I apply the same tools and techniques for developing and testing web apps to my Facebook apps?

Well, as with many things in life, the answer is yes and no. Sure you can use PHP and your favorite tools to build your app. However, because of the uniqueness of the Facebook Platform, there are special considerations that you need to think about when testing a Facebook app. Perhaps you’ve already encountered some of these special issues:

• How can I perform load testing on my app without defining hundreds, if not thousands of phony Facebook users, and how do I control them all? (…and BTW, defining phony users violates the Facebook Terms of Use Section 4.1)
• If I’m doing performance testing, how do I factor out the time spent at the Facebook servers during API calls and FBML-to-HTML rendering?
• Are there special security issues for social media applications, and how do I test for these?
• How do I tell if if my application is usable?
• How do I test my application when our development schedule is already behind?
• Are there any special issues when testing applications written for Facebook Connect?
• How do I do proper load testing when Facebook doesn’t allow me to hook up automated test tools? (Again, check the Facebook Terms of Use Section 3.2)
• Now that Facebook will proactively apply their Developer Principles, how can I be sure that my app doesn’t violate them?
• How do I test in an environment where the Platform is constantly changing?
• How can I simulate some of the error conditions that Facebook returns when I call API functions so I’ll know my app is robust?

We plan to discuss these, and many other similar topics here. But mostly, we want this to be a resource for you. If you have a question or topic that you’d like discussed, or want to be a part of our ongoing knowledge base of Facebook testing, please let us know at admin@testfacebook.com