The problem with web services

While creating the tags from contacts demo last night I was reminded of one of the big problems people don't really mention about web services. They can be really slow.

I had intended to offer the demo up as a live service so you could see the results for any flickr account. Coding this was easy. Only issue I found was that each page required (n+3) requests to the flickr api (3 to work out who the user is, and the rest to get the tags for each of their contacts). This meant that for some of the more popular people I tested, generating a page was often taking well over 30 seconds, which is too long.

One factor here is that it's not an quick and easy dataset to calculate, even with a direct connection to the database. Most uses of an API wouldn't require quite so many requests. And caching would help a little, but only if the script was requesting info on the same users all the time, which I'm not sure would be the case here.

So I'm wondering if these kind of factors are likely to limit the kind of functionality prototypes it's possible to build using web services. After all, the demo would have been easy if flick.contacts.getPopularTags() was available.

< previous next >