An interesting discussion emerged today about whether Ajax and other Rich Internet Application Application (RIA) technologies like Flash and Flex, will end up overloading Web infrastructures in the future. Tim Bray has a very common sense explanation of the issues in his The Cost of Ajax piece today, the issue over which James Governer originally pointed to. I tend to side with Tim that the "Does Ajax hammer Web servers?" questions tend to be hand-wavers that don't expose the real issues. I've talked about this in the past (The State of Ajax: Progress, Challenges, and Implications for SOAs) because being a good distributed services citizen is something all Ajax software designers will have to aspire to. Particularly as the entire Web is presently busy turning into a seaof reusable, open APIs, a growing trend that essentially turns the Web into our very own Global SOA.
If case you wonder why this is significant in the large, it's because RIAs are a crucial aspect of Web 2.0 software. This is largely because they allow robust interaction with the user and add rich media elements such as audio and video to the two-way Web; Ajax is one reason that Flickr is so good, for example. So RIA techniques, including Ajax, are dynamic browser technologies that support the development of Web 2.0 software that more easily harnesses collective intelligence, facilitates mashups (because RIAs tend to prefer the use of data-based Web services as opposed to pulling information off of HTML Web pages), and other fascinating aspects of the next generation of the Web.
The problem is that things like Ajax are enormously powerful techniques that can trigger lots and lots of work on far-away computers very quickly, all in the background using the potent XmlHttpRequest(). In fact, in a humorous piece a while back (Five Earth-Shattering Things You Should Know About Ajax), I discuss how a simple, poorly conceived Ajax program could easily bring the biggest, brawniest server in a data center to its very knees. And unfortunately, that's inevitably what's going to happen in some cases. I see a lot of the RIA tools, particularly around Flash, being given to Web page designers who are brilliant artists but quite inexperienced Web architects. And I'm now starting to see the same thing with Ajax development tools.
The crux of the issue is that these powerful tools make it a simple matter to trigger vast amounts of work on the back end of a network using relatively innocuous looking requests (Tim rightly gives an example of "a complex outer join on two ten-million-row tables (i.e. very expensive).") Or such things as tying an Ajax request to a mouse over event, ensuring that lots of Web traffic will occur whenever the mouse is dragged. I once saw something like this years ago on a project with a Java Applet that offered browser-based wildcard searches on a multi-million row customer database. The result: Searches that never stopped streaming back to the client in many cases, such as a simple customer search retrieving every customer whose last name starts with "s". This underscores the importance of knowing the true cost of a server-side request.
Moore's law, and leaps and bounds advances in network bandwidth (which grows faster than Moore's Law), does sometimes mask these problems in their early stages. But in the end, any amount of computing power can always be squandered by some poor design decisions. And this is where understanding your design context comes in. Specifically, ascertaining the cost of a given request over the network. Making the server-side cost of operations very clear to Ajax client developers should probably be all over Web API documentation, though I warrant it'll be a while before it happens.
So I would turn James Governer's question into a statement: that Ajax can in fact senselessly pound a big server into the ground given a set of Web services that allow poorly chosen requests to swamp it. And sure, to some extent this will be avoided with proper design and testing, however we all know the right people often can't or don't get involved at the right time.
But, and here's the rub, services not-invented-here are going to become much more common in future Ajax applications. By this I mean external APIs from Web services in the "cloud" that has data that you simply won't be able to live without. And this constraint puts, no, forces some common sense back into the client. Because it will be unavoidable that poorly designed services, over which you have no control, will have to be used in a given mashup development effort. So putting checks, filters, caches, limiters, and smarts into the Ajax client will simply become standard procedure to avoid bad behavior, both on the client and the server.
It's like Tim Bray said in his post, when used properly, Ajax can even result in a net win, saving network and server bandwidth. In fact, I think the original problem might even be stated inversely, the problem is that Web services, particularly on the Web -- but also in SOAs -- will have to deal with capricious, unexpected use. And not because of poorly designed Ajax. The real culprit: You won't necessarily know who is using your services and why. Demand may come out of nowhere if someone builds the Next Big Thing out of your Web service. For this, I say it will be users that will ultimately hammer the servers, not Ajax.
Important Side Note: I'll be heading to Real-World Ajax in San Jose over the weekend. On Monday I'll be giving a noon time presentation on Ajax Patterns and Best Practices. Jesse James Garrett (the creator of the term "Ajax"), David Heinemeier Hansson, Google's Adam Bosworth, Paul Rademacher of the famed mashup, Housingmaps, and many others will be there. That means I'll be in downtown San Jose from Saturday evening on. If you want to meet up, let me know!
Calling a service over the Web in response to mouse hovers is a really bad design decision. What other silly Ajax tricks have you heard of?
links: del.icio.us
The important point here, and the one which will be causing the problems
when they occur, is about the economics.
