Published in Contingency Design on Thursday, February 19th, 2009
This post comes a bit late in the whole web 2.0 cycle. I feel that it bears repeating because I have come across sites that don't follow some basic principles when pulling in 3rd party data from sites such as flickr, twitter et. al.
The blessing of popular and easy to use APIs and the data portability of web 2.0 applications has had an unfortunate side effect, and that is that some implementations that use these services do not integrate appropriate contingency design should these 3rd party services fail.
Caching data calls to APIs is a good bit of contingency design. Many APIs will require caching - like that of Amazon - but I suspect this is intended to help limit resource use of the API host, not the site using the API. The reasons a person using API accessed data on their website would want to cache the data are:
A simple implementation to handle those two cases would be one that caches an API call for a given amount of time and one that freshens stale cached data and triggers an error should an API call fail.
As I said above, this post is a bit late to the party but it is worth writing as recently I have come upon at least three sites where firebug and other widgets have revealed issues retrieving API fetched data and the site loading times have been horrible.
A decent implementation idea would be to roll your own caching wrapper and agnostically plug it in to a stable caching tool, perhaps something like Cache Lite for PHP. In this manner you have a reusable, caching library independent piece of code that can handle caching/flushing and refreshing of data which could function to handle the two cases discussed above.
And that's it. It's been 541 days since my last post. Wow. I hope this is a re-start of a new phase of blogging.
Right, and it looks like I had not built the commenting functionality into this version of the site. What a surprise. I'd still like feedback so if anyone has any email me at mike at this domain and I'll pop a comment right into the database. Off to build some commenting functionality... Comments should be working now.
I started freelancing by diving in head first and getting on with it. Many years and a lot of experience later I was still able to take away some gems from this book, and there are plenty I wish I had thought of beforehand. If you are new to freelancing and have a lot of questions (or maybe don't know what questions to ask!) do yourself a favor and at least check out the sample chapters.
Like the other books listed here, this provides a great reference for the PHP developer looking to have the right answers from the right people at their fingertips. I tend to pull this off the shelf when I need to delve into new territory and usually find a workable solution to keep development moving. This only needs to happen once and you recoup the price of the book in time saved from having to develop the solution or find the right pattern for getting the job done..