tags:

views:

465

answers:

7

Watching the effects of today's Google outage across the web got me thinking about how to prevent this in the future. This may be a stupid question, but is there a good way to include external APIs (e.g., Google's AJAX libraries) so that if the API is unavailable, the including page can still soldier on without it? Is it generally a bad idea to use libraries hosted on an external server in general?

+7  A: 

It's unavoidable to use a script tag to load cross-domain JavasScript files (this will cause a timeout if it goes down). However, in your code, check for the API objects being null to avoid errors:

E.g. instead of:

<script type="text/javascript">
  google.load("maps", "2");
  // Use Maps API
</script>

use:

<script type="text/javascript">
  if(google != null)
  {
    google.load("maps", "2");
    // Use Maps API
  }
  else
  {
    // Fallback
  }
</script>

I don't think rare outages are worth rejecting an external API wholesale.

Matthew Flaschen
A: 

A lot of the time you need to access third party libraries over the web. The question you need to ask yourself is how much do you need this and can you cache any of it.

If your uptime needs to be as close to 100% as possible then maybe you should look at how much you rely on these third parties.

If all you are obtaining is the weather once an hour then you can probably cache that so that things carry on regardless. If you are asking a third party for data that is only valid for that milisecond then you probably need to look at error handling to cover the fact it may not be there.

The answer to the question is entirely based upon the specifics of your situation.

Robin Day
+1  A: 

I think its a great idea to use external libraries since it saves bandwidth for me (read $$). But its pretty easy to protect against this kind of api outage. Keep a copy on your server and in your JavaScript check if the api has been successfully loaded. If not load the one on your server.

I was thinking about jQuery and YUI here. The other guys are right about the problems when using actual services like mapping.

adept
+2  A: 

The best general answer I can give is, degrade beautifully and gracefully & avoid sending errors. If the service can become unavailable, expect that and do the best job you can. B ut I don't think this is question that can be answered generically. It depends what your site does, what external libraries/API you are using, etc.

You could do some sort of caching to still serve up pages with older data. If allowed, you could run the API engine on your own server. Or you could just throw up status messages to users.

It's not a bad idea to rely on external APIs, but one of the major drawbacks is that you have little control over it. If it goes away? Welcome to a big problem. Outages? Not much you can do but wait.

jskulski
A: 

It'd certainly be fairly easy to include a switch in your application to toggle using Google or local web server to server your YUI, JQuery or similar library so that you can toggle provider.

David Caunt
+1  A: 

One possibility for mitigating the problem (will only work if your site is dynamically generated):

Set up a cronjob that runs every 10 minutes / hour / whatever, depending how much you care. Have it attempt to download the external file(s) that you are including, one attempt for each external host that you depend on. Have it set a flag in the database that represents whether each individual external host is currently available.

When your pages are being generated, check the external-host flags, and print the source attribute either pointing to the external host if it's up, or a local copy if it's down.

For bonus points, have the successfully downloaded file from the cronjob become the local copy. Then when one does go down, your local copy represents the most-current version from the external host anyway.

Chad Birch
+3  A: 

You will want to design your application to degrade gracefully (as others have stated) and there is actually a design pattern that can be useful in doing so. The Proxy Pattern, when implemented correctly can be used as a gatekeeper to check if a service is available (among many other uses) and return appropriately to the application either the correct data, cached data or inform the application that the service is not available.

Jon Erickson