The Client-Server See-Saw

Modern apps usually come in two halves. One half of the app lives in the browser or the local operating system, whether desktop or mobile. The other half lives on a remote server, or in a cloud cluster. These halves are called the client and server environments respectively.

The delegation of tasks between the two halves has changed over time. Originally, for the first client-server applications, the internet was very slow and computational resources (CPU time and memory) were expensive. This meant that the client had to bear the brunt, and remote servers were only consulted when absolutely necessary. One of the first uses of remote servers in this respect was for software registration.

Gradually, bandwidth and connectivity improved. Dialup gave way to broadband, and the expectation that computers were always connected. A greater percentage of computer users were going online. Despite this, growth in internet usage was mainly focused on the use of the browser, and the browser was limited to displaying simple web pages.

The Modern Era

Two subsequent developments changed this state of affairs: the rise of mobile, and the improvement in browser efficiency. Mobile platforms saw the rise of platform-specific apps, mostly on iOS and Android. As browsers improved, JavaScript became faster, and what had started out as DHTML techniques in the 1990s soon evolved, through Ajax, into HTML5 and web apps that are even starting to compete with native performance.

These developments had consequences for the delegation of tasks across the client and server. As connectivity had now improved, the rise in the number of apps across both mobile and browsers saw actions increasingly being pushed to the server-side. This was especially true of mobile apps in the “social age”, with many mobile apps simply being thin clients giving access to closed-silo websites like Twitter, Facebook, and Flickr. This trend continues to the present day.

Clients, then, started out as the primary place to do the work, with the servers being relegated to only secondary tasks. Present day clients are secondary, however, and everything is computed and stored in the cloud, often in closed-silo style, proprietary to individual companies.

Yet, once again the tide is changing.

Client-Side Phoenix

Servers presently have the upper hand in terms of delegation of tasks in client-server apps. In fact, even some extremely unexpected delegations are starting to happen, such as the rendering of games in cloud GPU clusters for display on mobile. Some of the circumstances that led to the rise of server-side are not changing. Companies want to horde user data, for example; in many ways it makes strong business sense because analytics trumps the small cost of development and storage. But other circumstances are changing. Mobile platforms, for example, are getting faster and faster. While not yet competing with desktops, they are closing the gap at an astonishing rate.

Meanwhile, client-server apps face a number of problems, and these are being increasingly highlighted. One problem is that as mobile becomes more popular, so our expectations of connectivity exceed the reality. When internet enabled mobile devices first became widely popular, it was a revelation because previously connectivity had meant sitting at your desktop computer, sat on a desk in a room somewhere. Suddenly, you had internet when walking down the road, internet in your local shop, internet in the park. This seemed like a massive boost in connectivity. And it was, but…

Connectivity is not perfect. Going through a tunnel? Going on holiday to a far flung country? Hiking in the mountains? Now that we’re used to being connected almost everywhere, the “almost” nature of this proposition becomes more noticeable and more galling. This is especially so the more that client-server apps absolutely rely on the server side of the equation. When you go offline, suddenly most of your apps—be they mobile, browser, or even many native desktop apps should your network connection go down at home or in the office—are unusable. This is not good design, and can be prevented.

Another overrun in expectation comes in responsiveness. Computers always seem to be getting slower. We expect apps to open instantly. We expect tabs to close as soon as we click them. We expect messages to be sent and received instantly. In practice, 80% of the time this actually does occur—but again, the 20% exception is galling. And studies consistently show that bad responsiveness leads to decreased revenue. There are many problems that can lead to bad app responsiveness, but one is simply delegating too many tasks to the server-side, and then incurring the cost of latency when there is a problem with the network. Sometimes this can happen due to bad asynchronisation within the code, but often it’s just an unavoidable property of the network.

Now that we have so many devices—not just mobile, laptops, desktops, but increasingly other devices in the internet of things—we’re finding problems with a “one size fits all” approach to design. Web pages, for example, can look great on a desktop and terrible on a mobile. This applies to apps that are supposed to work across all devices too: getting all of the apps working with similar functionality is difficult, and takes up a lot of developer cycles. Not only is it expensive, but it’s quite fragile too.

So here we have three problems with mostly-server-side apps: connectivity, responsiveness, and device proliferation. Yet, at the same time, client-side environments are getting faster and faster. And people are starting to notice that the status quo can be changed.

Conclusion

At the dawn of the connected era, client-side apps were standard. As servers became more powerful and connection to the internet more pervasive, social and mobile entered the scene. Suddenly, apps emerged everywhere, often in the form of thin clients for almost entirely server-side hosted services. But this state of affairs is changing, and due to the proliferation of more powerful clients, client-side is making a comeback.

In the next post in this series, we’ll take a look at a new cloud service model called BaaS, which is making client-side more attractive to target by bundling up existing server-side framework patterns into easy to use APIs.

Have you had to manage the client and server sides of an app? If so, which side did you find easier? And are you finding that the client-side is making a comeback in your company or organisation? Let us know in the comments below!