External dependencies

Columbia, Maryland © Leon Fayer

In this day and age, more and more applications leverage external services. So much so, that only about 6% of all sites has no 3rd party content and almost 40% of all site have between 75% and 99% 3rd party content. And for a good reason. External services provide a tremendous benefit, not only in brand familiarity and content, but also in cost saving, considering you’re leveraging years of someone else’s work for your gain.

However, one of the major risks when implementing a third party service is the reliance on the availability of that third party service. Availability of your production site. Based on the service that you have no control over. And no matter how large or successful the service that you’re using is — it will go down (or become unavailable) at one point or another. Perhaps the best example of it is using Google CDN for jQuery, only to realize that your site will break for all Chinese users, since, you know, China blocks all traffic coming from Google.

And so we have a conundrum. We should (and do) use 3rd party services, sometimes extensively, yet our systems become more volatile because of that. Luckily there are a few golden rules to follow when implementing 3rd party service.

1. Only connect to a third-party service where needed. Don’t try to connect to SSO on every page load to validate that a user is still, in fact, the same user you displayed the previous page to. Cache the results locally.
2. Avoid external connections on critical path. This is the core idea behind putting all your JavaScript in a footer of a webpage. Don’t load Google Analytics as a first thing on your page, you will delay the display of the content that actually matters. Make the connections after your content is loaded, or better yet — connect asynchronously.
3. Trap time-outs and errors. You do it with your database connections, why would you treat external connections differently?
4. Create a fallback plan. You have no control over external services, but you do have the control over the content presented to your users. If external images are the essential feature of your site — store them locally after the pull, so you can fall back to the latest available content in case the service is unavailable. Remember, often times stale content is better then no content at all.

So how does it all translate to a real example? Let’s take a basic example of pulling data from external source in JavaScript with jQuery XHR call.

$(function () {
  $(document).bind("ajaxComplete", function (e, xhr) {
      if (xhr.statusText == 'timeout') {
        // pull local content
      } else {
        // use content from response
      }
  });
        
  $.ajax({
    url: 'http://example.com/feed.json',
    dataType: 'json',
    success: function (data, status, xhr) {
      // generate consumable content from response
    },
    error: function (xhr, status, err) {
      // pull local content
    },
    timeout: 3
  });
});

XHR requests are asynchronous by nature, which automatically removes the load time from critical path, allowing your content to be loaded independent of 3rd party service latency. Error trapping also accounts for blatant service unavailability or problem by pulling local content if error is detected. And a part that most people forget, latency detection is also enforced via timeout flag and check of response status.

That’s all. A couple of parting thoughts:

• In modern web applications external dependencies can be nested. Use the sanity check list above for all of them.
• Latency is a performance killer. Make sure you utilize caching to reduce number of external requests to an absolute minimum.