Back in March, we predicted the imminent announcement of the Facebook location-based service. Well, we were a little early on that call as Places was announced by Facebook yesterday.
Places is an exciting new turn for Facebook as many cool features and applications will be built using it, and Yes Virginia, FriendRunner will fully support it so that you may load test your location-aware Facebook application. Places is built around the idea of users “Checking in” at places from their mobile device so that their friends and applications can know where they are and where they have been. From a functional point of view, this looks a lot like foursquare.
Facebook has created an API so that applications may interact with Places. Currently, this API only supports Graph API apps, so those of you who are building with the classic RESTful API are SOL. I don’t think this will ever change, as trying to represent something as rich as location using something as complex as the RESTful API will simply end up as a fiasco. Facebook currently allows developers to read users’ checkin information, and some time in the future (apparently currently in private beta) applications will be able to make checkins on their own.
Alright, so where does FriendRunner fit into all of this. Well first off if you weren’t aware, FriendRunner does support, and we absolutely love the Graph API. Without that support there would be no way for us to implement Places. Now the reason we love the Graph API so much is that it’s so well thought out and regimented that querying a list of user checkins looks exactly like querying a list of user friends which looks like querying a list of a user’s favorite books. This means that we should have this support coded up fairly soon so that when you’re ready to load test your location-aware apps, FriendRunner will have you covered.
So go at it and start using location-awareness in your Facebook applications. When the time comes to test these features, let us know how FriendRunner can help you.
Contest
Since we’re talking about places and locations, see if you can identify the beautiful Georgian mansion featured here. This National Historical Landmark was built by a signer of the Declaration of Independence and was once (a long time ago) the workplace of Sericon Technology’s president. When you think you have the answer, let us know at contest@friendrunner.com. The first one to correctly answer will be featured on this page, and will enjoy worldwide fame from people who love testing Facebook apps. Extra credit if you can also provide the house’s coordinates.
Winner
Dr. William M. Spears of Swarmotics has correctly identified Homewood House on the campus of The Johns Hopkins University as our mystery location. He’s also noted its coordinates as 39°19′46″N 76°37′9″W, as well as adding his personal comment that it is a “Good frisbee and tanning location (i.e., the ‘beach’).”
Congratulations and good work William!
Are you planning on writing a Facebook application that will go really viral and have millions of users? Do you avoid discussing the number of users you think your app will attract for fear that people will think you’re crazy? Then this is for you.
Facebook recently updated their Developer Principles & Polices document to deal with applications that have huge numbers of users or make lots of API calls to the Facebook server. This document, which your application needs to meet the requirements of, contains a short section (II.11) about very popular applications. It now states:
If you exceed, or plan to exceed, any of the following thresholds please contact us as you may be subject to additional terms: (>5M MAU) or (>100M API calls per day) or (>50M impressions per day).
Clearly, they’re concerned about large and popular applications overwhelming their infrastructure, and want to deal with them proactively. It isn’t commonly known what Facebook’s additional terms are that large applications need to meet, but it’s certainly reasonable for them to exist.
So what’s the FriendRunner connection? Well, if you’ve got more than five million active users, congratulations, but you’re going to have to abide by the additional Facebook rules. However, if you don’t have that number of users but you’re pushing against the hundred million API call limit, FriendRunner can possibly help. One of the things that FriendRunner does well is allow you to profile and debug the API calls that your application makes to the Facebook server. If unnecessary or redundant calls are being made, FriendRunner can help you find them to decrease your use of the Facebook server and possibly avoid any additional terms that you must meet.
One of the more interesting announcements coming out of f8 was the relaxation on the prohibition of cacheing data for more than 24 hours. Now I’ve always thought that this prohibition came from the privacy world – don’t save people’s information because it isn’t yours. Turns out, it isn’t a privacy thing at all – it’s really a user experience issue. The problem with holding on to people’s data is what happens if it changes? If you store the data and rely on it being current, things will fall apart when the user changes it several weeks from when you stored it. However, if you can only hold onto it for 24 hours, the chances of something going wrong go down dramatically.
These concerns go away now because of the new service that allows developers to register with Facebook to be notified when a user’s information changes. This will allow any cached data to be updated without any concerns of getting out of whack. This can dramatically simplify writing applications, and it was one new feature that seems to be universally embraced by developers.
And how does this affect FriendRunner? The FriendRunner profiler features that allow developers to see what APIs get called during the execution of their application become more important. There is now no excuse at all to call the same API with the same data, since the result may be cached, FriendRunner can help you find these types of problems, and identify places where you can optimize your code.
The new Facebook Graph API announced at f8 represents a revolution in the way that Facebook applications will be developed from here on in. You want to get a list of a users’ friends? No longer will you need to weed through the PHP documentation to try to figure out which API to call, and which parameters to pass. Now, all you need to do is make a simple RESTful HTTP call, and get a nicely formatted JSON response in return. How do you format the REST call? Pretty simple, I’m guessing that after you do 2 or 3 of these it will become second nature, and you won’t even need to look at the documentation.
So how will this affect FriendRunner? My initial thoughts is that it will affect FriendRunner in a positive way. All of the original API will still be in force, so nothing there will change. What will change it that FriendRunner will need to support all of the REST API calls at https://graph.facebook.com. But that won’t be so hard because it’s simply getting at the same data that we already provide, just in a different way. But even if it is hard, that’s okay – we subscribe to the “Why does Rice play Texas” philosophy.
Since the RESTful API is language agnostic, the FriendRunner support can be written any way we want, and not necessarily in PHP. This makes us very happy.
Stay tuned to get more information about when we’ll have the new API coded up and ready. In the meantime, all of the investment you’ve made in wriing Facebook apps the old way is secure, and your apps will continue to work. And FriendRunner will continue to be available for testing them.
Facebook, Features | admin | 
August 19, 2010 4:27 pm | 
Comments (2) 
Subscribe
