Had to update a set of Facebook applications for WCM. (Yup, still freelancing a little for them.) This is the third time these applications have needed a major upgrade to meet Facebook’s ever-changing API – once to migrate from FBML to FBJS, and again to move to Oauth, and no again to meet Oauth 2.0 as iFrame tabs and apps.
Facebook, being the 800 pound gorilla, can do whatever it wants, and the developers who have invested so much in the platform will, ultimately, get in line or just fail entirely. But this really hurts the small developers with modest projects, especially as some of the standby Facebook apps like Static FBML die out and paid services start charging “enterprise” prices.
To Facebook’s credit, they’ve put effort into sunsetting APIs cleanly, with advance warning (sometimes as little as 4 weeks, but usually quite a bit better) and even letting old APIs continue to work… for a while. But they haven’t handled QA at all well, which is exactly where this problem hit.
In the case of this client of WCM, they have a handful of custom, fan-gated tabs, as well as a full blown contest application, which was custom designed to meet their jurisdiction’s gaming regulations. (Otherwise, they could probably get away with any of the other contest apps out there.) When Oauth 2.0 was introduced, Facebook accidentally introduced a boatload of bugs into the supposedly still-supported legacy authorization API, which meant that in the middle of a major promotion, the contest stopped working entirely. This led to a crunch day of moving to the new APIs, which were still buggy as heck and not nearly as feature-rich as the old APIs.
Due to these holes in the API, a great deal of the work had to be custom built using curl commands and manual decoding of returned data, and other nonsense that really shouldn’t have been necessary since Facebook’s published PHP library ought to handle that sort of thing. Luckily, the tab-based apps weren’t affected (they didn’t need to authorize visitors); and since the new API, inexplicably, couldn’t handle fan-gating, they weren’t transitioned.
So now Facebook has killed support for the old API entirely, and requires tabs to move to iFrames (just like applications always have). Because of this, the fan-gating on the tabs (remember, they COULDN’T transition to the new API when it was first released!) broke, and again, WCM was in a crunch with the client since they were in the middle of a major Facebook promotion.
This much is good: The new API, iFrame tabs, and Oauth 2.0, now that they’re mature, are a lot easier to code for than the old system, so the old apps were fairly easy to set up, even though one of them (due to its reliance on non-iFrame-compatible FacebookJS) had to be entirely re-written from the ground up. Everything was no longer on fire within 3 or 4 hours. But there are, of course, lingering bugs due to the major changes in how an iFrame app needs to be managed, which present a substantial challenge to fix, since Facebook’s documentation in regard to these little bugs is limited to the old API – entirely useless.
Okay, enough of my bitching. The end result here is that in order to be a Facebook developer, you need to be on the cutting edge of their API at all times, but only RELEASE when Facebook gets around to making the new API stable and complete, which sometimes doesn’t happen until after they’ve broken your app. Meantime, you’re praying that your clients don’t get stuck with something that just plain doesn’t work because Facebook accidentally introduces bugs/improvements into their legacy API.
As Facebook looks to extend the Facebook platform outside of Facebook, this becomes untenable. If I’m relying on Facebook for users to register for my site, it simply has to work 100% of the time. I cannot be required to update substantial portions of my applications and websites multiple times each year. Doing so doesn’t make me any money, so unless I’m Wildfire or another company that can spread that cost over a large number of clients, it ends up being a drag on resources and revenue. This, of course, is why Buddy Media and the rest can start jacking up their prices from hundreds of dollars each month to thousands, leaving smaller companies to use the low cost tools which end up falling behind the API… same problems. (Ironically, even Facebook’s cut-and-paste social plugins have fallen behind the API and required instant upgrades to new code.)
So what am I doing? Well, nothing at all that’s mission-critical is ever going to be integrated with Facebook. I know there are benefits in hooking these things up, but I can’t afford maintaining these things or losing functionality because I overlooked a blog post. For clients, it’s going to have to be a program built by one of the major Facebook app companies, and they’ll have to cover the cost.
It’s a shame, too. My clients have seen awesome results using some clever custom applications, but if I can’t guarantee a modicum of reliability and uptime, the hit on my reputation will far outweigh a handful of successful campaigns.
