Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
17 April 2012

Client or server?

By Andrew Clifford

Like many design questions, deciding whether to perform processing on the client or the server depends on who you talk to.

Many applications perform some processing on the client (or PC) and some on a server, and the designer needs to decide what processing runs on which.

The server is a more controlled environment, and is the right place to manage data and implement business rules. In a web-based application, the server sends the results of this to the client as a web page.

The browser on the client is responsible for interpreting the web page and interacting with the user. In some case, the web page is just displayed by the client. Many application provide additional user interaction, typically written in JavaScript.

The split of responsibilities between client and server is generally easy to understand. The boundary between client and server can be modified, for example carrying out more on the server if more control is required, or more on the client if more interaction is required. But wherever you draw the boundary, there can be situations where it is difficult to decide where to put the processing.

We hit this situation in our Metrici Advisor assessment tool. Assessment results are collected into result sets. This uses incremental recalculation and caching, which are best done in the well-controlled server environment. Showing the results, in tabular or graphical format, is best performed in the client browser.

Some processing falls in between these two, such as selecting which rows and columns of data to show, and preparing data for export, for example as CSV.

In cases like this the designer needs to weigh up the strength of requirements for server characteristics and client characteristics. In this case, processing on the server would allow views of the data to be pre-calculated, cached and combined, and reduces the amount of data transferred between server and client. Conversely, processing on the client would provide a more instantly interactive experience, and closer integration to other client features such as graphics. We need to weigh up the relative merits of each.

However, to be honest, it is hard to make a completely rational choice because the designer will generally be more comfortable with one environment than with the other. I am as guilty as anyone on this. I grew up using mainframes and dumb terminals, and err too much to server-based processing. So my applications are robust and well controlled, but a bit clunky. These days the opposite is probably more common, with developers with a good knowledge of web technologies putting too much in the browser, giving richly interactive applications which look good but are not so robust. Architectural decisions like the split of processing between client and server are more often dictated by the past and preferences of the designer than a rational analysis of requirements and capabilities.

In this case, working with a colleague who is more steeped in client-based processing, we have compromised on a single JavaScript component that can be used on the server or client, which I believe is a good solution. It is only by recognising our biases, and working with people with different viewpoints, that we can create the best designs.

Next: Defending change


To subscribe to the newlsetter, simply send an email to
Privacy policy

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Try it for free!

Find out more