The Wildly Inconsistent Facebook

When developing for Facebook, you’re bound to run into issues you would never dream of because they are inherently problems within their system. What follows is a laundry list of issues I’ve ran into, mostly with the graph API, that have caused many wasted hours and many rage / swear filled minutes:

• Paging Data: Of all things, I think this really bothers me. Something as simple as how data is set up for retrieval is inconsistent. Between different calls (e.g. requesting photos the user is tagged in, or grabbing user statuses) the previous/next links in the returned paging data can lead to very different results. One call may lead to a duplicate entry on the next page of data, the other may not. Some calls, even the most basic such as an inquiry into basic user information, throw a stream error in Internet Explorer. Other calls will throw this error only when reaching the end of their data while in other browsers it will show up with an empty data set only. Recently an application of mine broke and I couldn’t figure out why until I found out that the in the final page of data for a certain request, the paging data “next” link was pointing back to the page it originated from, leading to an endless loop.  I find for every new project, I’m forced to manually check through sets of data to see how the previous/next links behave and to see how reaching the end of the dataset is indicated. Countless wasted hours for something that I would expect even the most junior programmer to have set up consistently.
• Crossdomain Policy: Typically the crossdomain policy for the graph API is fine, that is until you run into any users who may not have set a profile picture. These standard profile picture placeholders are hosted on some other random domain causing security violations when in Flash. One of our clients had kept complaining the application was breaking and it wasn’t until I logged in with their account that I saw what the issue was. Now I check if a security violation has occurred and then display our own locally hosted version of a placeholder picture. Mind you, I can’t tell if the user if male or female if they haven’t decided to share that information so I typically just throw up a generic silhouette.
• Erroneous Data: Recently I was fetching friend statuses through the graph API, and since I wanted to organize the posts by time posted I was also fetching the updated_time parameter. My list kept showing up only partially organized and after looking through my code I realized that the incorrect time was actually what Facebook was sending back. The times would appear to be hours or days into the future, even though these were people in the same timezone as myself and had correct times shown for their status on their Facebook page. When fetching the same data through their in-the-process-of-being-deprecated Facebook Query Language (FQL) the date was utterly absolutely perfectly correct. How in the world do you store the date properly on your servers, but somehow mangle it in the process of sending it through the graph API?
• OAuth Tokens: Requesting and validating a token is the core of any application. So how can this possibly go wrong? After countless wasted hours I realized that one of the accounts our client had sent over as having problems using the application we built for them was having its token magically go poof. For those of you interested, here’s the bug entry http://bugs.developers.facebook.net/show_bug.cgi?id=15933 Strangely, half way through testing the problematic account it started to work on its own. In my case the application was receiving a valid token, so it would try to load up, but when it would try contacting the graph API for more data the token was seen as no longer valid. How can a session be valid for all of one second?

Problems like the preceding are why Facebook initiatives like “Operation Developer Love” make my blood boil. When a company is outright careless, sloppy, and obviously clueless to any concept of code standards or of quality assurance, they cannot possibly think they’re doing developers a service. When you code for your own use you’re the only person staring at your inconsistent mess. When you code within a team, you have team members who will ream you out for your sloppy inconsistent mess. When you develop an API that’s used by thousands of other developers, we all suffer. Facebook development team, you need to get your act together. Hire some senior people, maybe people with management skills who can enforce consistency and performance. Tear it all down and start again. Or if you can’t manage to do that, just don’t allow any applications to be built on your “platform”. That way only your team is suffering.

Advertisement

Tags: development, facebook, graph API