soapui-5-banner

Facebook Plug-in Crashes the Party: Is Defensive Coding the Solution?

facebook crashers

It finally happened: Facebook broke the Internet. Well, not exactly. In fact, you may not have even noticed anything was wrong. But last night, for a brief period, a bug in a Facebook plug-in caused dozens of sites to become unresponsive. Pages on websites including The Huffington Post, CNN, and BuzzFeed were rendered useless by this error, which redirected visitors to a Facebook error page, rather than showing them the content on their desired site. Wasn’t it just a week ago that the Facebook Javascript API went down, taking with it the  ‘Likes, Comments and Apps’?

And we’re expected to work under these conditions??!!

Like I said, because this most recent issue was cleared up relatively quickly, you may not have even noticed anything was wrong. But this does bring up a question that is far too often overlooked on the Web: How much are you relying on other people’s code?

Seriously, take a second to think about it. How many third-party APIs are integrated into your website, app or even mobile app? How many different companies are you relying on to give your users the best experience possible? And is it really worth the risk of having one of them take down your entire site just so people can easily share your content on Facebook? It really is a risk vs. benefit conundrum. If you don’t rely on at least a few third parties to provide that extra value to your users, your content can’t be easily shared.

Trust me, I know it’s extremely difficult not to rely on at least a few external companies to provide that extra value to your users. I’m not advocating for anyone to stop integrating other people’s code into their own. What I’m saying is that there are ways to protect your app from unnecessary outages, while still providing your users with the value from another site.

  • Make sure you’re using the latest third-party APIs that are non-blocking or asynchronous
  • Limit, as much as possible, third-party calls from your mobile site
  • If possible, turn off third-party content when they’re under heavy load
  • Code defensively so you can gracefully take another path when the first one fails. 

In addition to the suggestions above, it’s worth setting up API monitoring so you can track those behaviours in production. You may find one API is less reliable than others or responds more slowly, which can lead you to swap it out – after all, your loyalty needs to be to your own customers and their experience with your site. At the very least, monitoring the third-party connections you’ve added will alert you to problems like the ones Facebook Connect had before your users start tweeting about it.

One other way to protect yourself is to code defensively so if a third-party API fails, your app continues to function. For example, if Facebook Connect goes down, can you revert to your own authentication and just do without the additional Facebook sharing benefits for that period of time? Monitoring real production behavior gives you the data you need to know where you need to build that defensive code.

All of this comes down to one thing: time. Of course, given enough time, everyone would test and monitor all of their own APIs and all of the external APIs that are integrated with their software. But think about it, if you don’t have time to test all your code and monitor all of your APIs, what makes you think the team that wrote the external API you’re using has time to do it?

Are you really willing to jeapordize the quality of your code? Shouldn’t that be the No. 1 priority: putting out high quality, valuable software. Not to mention that, by prioritizing today using real data from your production system and weighing the risk vs. reward based on your user’s experience, you may save yourself a lot of time and agony in the future.

See also:

3-hidden-gems-article
subscribe-1

Comments

  1. The first link leads to a login page on outlook.com

Speak Your Mind

*