Big changes coming to Facebook Platform

Today’s Developer Roadmap post by Facebook has outlined some big changes coming down the pike for Facebook Platform. Here are the big 3 changes (well, as far as we see them):

No new FBML apps

Facebook will no longer accept new FBML Canvas applications by the end of the year. These are the types of applications that launched the Facebook Platform way back in 2007 (the same year that saw the iPhone and The Simpsons Movie). FBML apps have a lot going against them, most importantly is the fact that there’s really no good reason to write them anymore. It used to be that developers who wanted to write Canvas applications had to choose between FBML and the simpler but not-as-powerful IFrame method.

But IFrame has now caught up and surpassed FBML in terms of power, so there’s really no reason why a developer building a new application in 2010 should even consider using FBML. There’s also another issue at stake here. FBML Canvas apps require all of the data traveling between a user’s browser and the application itself to be routed through the Facebook servers. This is a legacy design from 2007 that was done to give Facebook more control, and allow for user authentication, but it’s costing Facebook a lot of money to run these servers that do very little but act as proxies.

Since new FBML Canvas apps no longer provide any real value, and they cost Facebook a lot of money to support, Mr. Zuckerberg et. al. would like to just sweep them under the carpet. Looks like that’s what they’re doing.

Parts of the Classic REST API are being deprecated

Whatever we said about FBML apps is doubly true of the Facebook “Classic” REST API. Born in 2007, it now looks like patches upon patches with no coherent vision. It’s been so far surpassed by the Graph API that Facebook never even bothered to mention any non-Graph API support for their very important location updates yesterday. It’s been clear for a long time that this API needs to be put to rest, and deprecating parts of it is definitely the beginning. We can all say Amen.

OAuth 2.0 will be required for authentication

Another nail in the Classic REST API coffin. OAuth 2.0 goes hand in hand with the Graph API that Facebook would like to push everyone towards. Enough said.

Facebook has historically moved very quickly, which contributes to a good part of their success. Moving quickly means getting things out to customers quickly rather than perfectly and dealing with the consequences later. Today’s Developer Roadmapupdate is a good example of how to deal with those consequences, and will ensure that Facebook developers will continue to have loads of things to do as Facebook continues to innovate.

Location, Location, Location ummm…. Places, Places, Places

Facebook has just announced their long awaited location-based feature that they’ve called Places. Places is currently available from the Facebook iPhone app, or from http://touch.facebook.com/ if your mobile device supports HTML 5 and geolocation.

Places seems to be all about “Checking In” to places, a’ la Foursquare, although Places doesn’t seem to have the concept of “mayor” yet. In fact, it really isn’t so clear what the relationship of Places to similar services like Foursquare or Gowalla even is. On the surface, they’d seem to be rivals, but representatives from these other companies were on stage at the launch event. Everyone seems to be scratching their heads and asking “Why?”. Inside Facebook seems to think that everyone will play well together. On the other hand, All Facebook seems to think that Facebook is simply playing the proverbial cat that toys with the mouse before eating it. We seem to agree – Facebook is several orders of magnitude bigger than Foursquare and really doesn’t need them. Bye…

In other relationship news, Facebook has chosen to use Bing Maps instead of Google maps for well, mapping. Not a big surprise here, Facebook’s relationship with Microsoft > Facebook’s relationship with Google.

Facebook also seems to be making a big deal about privacy for Places. As if we’re all worried about Facebook’s use of our private data … There are also some safeguards to protect you from your friends playing pranks by checking you into the local strip joint, the free clinic, or Country Kitchen Buffet.

The name that Facebook chose for this service is also very interesting. Places vs. Locations. When you think about it, it makes sense based on the service that Facebook is providing. This service uses places (Katz’s Deli) as their atomically addressable entity as opposed to location (40° 43′ 20.33″ N, 73° 59′ 14.41″ W) which is far more precise, but amorphous. Facebook is clearly shooting at getting people to check in and tag real places to help fill up their Open Graph. This choice also seems to encourage developers to build location-aware applications around places and friends (since that’s what Facebook is all about) rather than real-time precise locations that one would need for say a citywide gaming application.

Which brings us to developers, APIs, and testing, the Raison d’être of this blog. Facebook is exposing user’s checkins to applications that use the Graph API (sorry Classic RESTful API developers – time to change). Currently, the only thing applications can get is checkin info using one of the following APIs:

GET https://graph.facebook.com/[checkin_id]

Gives information about an individual checkin

GET https://graph.facebook.com/[place/Page/user_id]/checkins

Gives a list of checkins that this entity has made. BTW, why can a place perform a checkin??

GET https://graph.facebook.com/search?type=checkin&access_token=ACCESS_TOKEN

Seaches for checkins

We’re told that an API to create checkin information from an application is on its way, or actually is in Double Secret Beta. Look for it soon, and then things will begin to get really interesting.

Zen and the Art of Facebook Application Load Testing (Part 4)

We’ve finally reached the promised land – this is the final post about Robert Pirsig’s book Zen and the Art of Motorcycle Maintenance . Thanks for sticking it out to those of you who’ve been following so far.

In the last post, we ended with an application that we can call nominally scalable. To get to this point we proved that the application scales well when going from one to two servers. In the process, we’ve figured out some important information such as how many virtual users a single instance of the application server can handle. Time now for the big test.

Run Test #3

This is pretty easy. Set up a deployment-quality infrastructure. Try and run SimulGoal users through it (remember that SimulGoal is the number of simultaneous users that the application must be able to support). See what happens.

Now some astute readers will recognize this as the same test that we warned about not doing back in Part 2. Aha, but things have changed now since we’ve followed a methodical plan where every step can either pass or fail, but will always teach us something about the system so that we can continue and be productive. We know a lot about the system at this point, so even if this test fails, it shouldn’t be too hard to hypothesize why, and then run another test to prove/disprove the hypothesis. In a short time you should be able to locate any problems still remaining, fix them and enjoy success.

And that’s the real point that Pirsig and Zen try to teach us – never finish a test where you scratch your head not knowing what happened. Always be making some progress. To do that, plan your tests out carefully, know what hypotheses you’re tryng to prove, and know which direction to go if the test passes/fails.

Conclusion

It’s taken us four posts to fully explain this methodology that we’ve developed while testing real Facebook applications. We’d love to hear your feedback  about what you think of this, both good and bad. How would you modify this to make it better?

Zen and the Art of Facebook Application Load Testing (Part 3)

In the last post, we continued the discussion of how Robert Pirsig’s book Zen and the Art of Motorcycle Maintenance can help guide us in some of the decisions we need to make when load testing a Facebook application. We defined some goals that the test should have, and we developed a way to determine ServerGoal, or the maximum number of simultaneous users that can be serviced by a Minimal Viable Server Infrastructure (MVSI) configuration of the test application’s infrastructure.

Once we’ve done that, it’s time to start Test #2 and determine whether the application appears to be scalable.

Run Test #2

In Test #2 we’ll increase the size of the MVSI and see how many virtual users we can push through the system. This can be as simple as using two application servers instead of one and seeing what happens. The natural instinct here is to say “This is a waste of time – doubling my computational power will double my capacity.”. Resist the urge to think this way. Claiming that you’ll double your capacity is a hypothesis - and a Big Brass Balls hypothesis at that. It needs to be tested, which is exactly the goal of Test #2.

So run a test with a double-sized MVSI and try to run 2*ServerGoal+(a few more) users through. Observe the breaking point of this system to determine what to do next:

The breaking point is more or less 2*ServerGoal

Well, it isn’t going to be more, so we don’t need to worry about that. If it’s close, then you’re in great shape since it appears that your application is scalable.  Don’t fall into the trap of saying that your application is scalable. At this point it only appears scalable. Is scalable is a hypothesis that you’ll need to test when you continue to Test #3.

The breaking point is much less than expected

You’ve got a scalability problem. There can be several reasons why this would occur:

• There’s a resource that’s creating a bottleneck and won’t let the application scale properly. A good place to start looking is anything related to a database.
• The application requires some stateful information that’s being stored in a problematic or non-scalable way. For instance, if a server needs to create a session with a client, a load balancer may need to take this into account and create a “sticky” session. If not done properly, problems will occur.
• There are problems with the configuration or network topology of the underlying server infrastructure.
• A whole lot of other possible problems …

The point here is that your hypothesis that the application is nominally scalable is just plain not true, and it’s pointless to go any further until this problem gets resolved.

Finding the cause of this problem won’t be easy, but if you do it in a methodical way you’ll get there. Look over the code and instrument it to write data into a log during critical parts of the processing. Consider running this instrumented code against Test #1 (with a true MVSI) and compare the logs against Test #2′s double MVSI system to see how the processing is different. This may lead you directly to the problem.Continue iteratively running Test #2 until you get this to scale properly.

Strap yourselves in guys, next time we go for the gold.