WebQueryOpen: the good, the bad, the final thoughts

A lot of developers are using a WebQueryOpen agent to render HTML from Domino: the IBM blog template, BlogSphere, etc. This made me as a 'senior' (read: old) developer wonder if I had to reconsider. I've always been told that QWO agents were to be avoided for performance reasons. But then: this was a wisdom from the old days of Notes 4 and 5. Several Notes/Domino bloggers joined the discussion. Stephan H. Wissel even pointed me a tool to stress-test web applications. Please use this tool with care and precaution.

The discussion

• Using a QueryOpen agent to render HTML pages, me
• How to Become a Yes Person With WQO Agents, Jake Howlett
• WebQueryOpen or not WebQueryOpen?, me
• Stress-Testing Lotus Domino applications with JMeter, Stephan H. Wissel
• WebQueryOpen Agents - The penny drops, Steve Castledine

My conclusion

For me, Steve Castledine has really nailed it. WebQueryOpen agents can be really useful and we don't have to avoid them, provided we don't exaggerate doing large iterative calculations or process large amounts of documents. The big secret of performant dynamic web pages is server-side caching. Document counts, tag clouds, calendars etc. only change when a blog entry is created or edited and saved. So they should be updated on save and stored in a cache document. A QueryOpen agent can then retrieve the precompiled HTML block and put it on the page. But then: in most cases a simple @DbLookup or @GetDocField would do this job as well.

The real advantage of WebQueryOpen agents comes when you cannot cache elements because they change too often or are too intertwined with other elements like translations of interface elements or security dependent items. They also prove great value when you want to give a lot of flexibility in rendering the page, as with portal pages and highly customizable templates.

Why use WebQueryOpen agents when we have Ajax now?

That was a remark on one of the blog entries. There are three main reasons why you would stay clear of Ajax:

• Accessibility: you want to make semantic websites that are accessible without the use of JavaScript or plug-ins.
• Performance: The major performance killers for a website are background images, mash-ups and Ajax. Just examine the performance of many advanced sites/blogs. Not only that the most Ajax libraries are huge, they also do a number of extra HTTP requests to retrieve data.
• Why use a more complex solution when a little LotusScript or @Formulas do the job easy and fast?

All this said, I definitely will rework my Archive, Calendar and TagCloud so that they are computed in LotusScript and stored in a cache document when a blog entry is saved. Rule: compute things only when they change and not every time you need them displayed.

Note however that I really am a big fan of the Ajax way. I enjoy programming in JavaScript for over 10 years now. But for performance reasons, I would recommend it only if it has good use. And I would strongly advise anyone against using one of the existing huge kitchen-sink Ajax libraries out there. In one of my next blogs, I'll explain what I think a lot of them are doing wrong.