Geeks With Blogs

News This is the *old* blog. The new one is at
Elton Stoneman
This is the *old* blog. The new one is at

The most recent project I’ve delivered has just gone live, and it’s a hybrid cloud/on-premise architecture which is becoming the norm at one of my clients. It’s a simple Web site, that needed to be delivered rapidly to make good on a sales promise, and the hybrid nature of the service layer enabled us to build and deploy very quickly (three weeks from “can you?” to “it’s live” – at an enterprise where the main product has a three-month release cycle).

The architecture is very simple:

  • Front end – not-quite-a Single Page App, rendered by ASP.NET MVC, with navigation done client side with a simple jQuery implementation (rather than a full-blown framework like AngularJS);
  • Back end – hybrid cloud/on-premise, with new data stored in Azure Table Storage, and existing on-premises services surfaced through Azure Service Bus Relay.

Initially the app is rolling out to one client. It’s expected to gain momentum quickly, but currently we’re getting all the performance and uptime we need from two Small-sized Azure Web Roles. When the site went live, I looked it up on my dev laptop to check out production performance, and I got to thinking about Single Page Apps, fat clients and thin servers.

When I browse to the site, ASP.NET MVC renders a single page of HTML, and as I’m navigating through pages, I’m really just hiding and unhiding various bits of HTML with jQuery. When I enter some data the validation is done with jQuery Validate, and when the page needs extra data, it’s an AJAX call to an API. Apart from the initial GET request and the final POST request, everything in between is client side, so all the work is being done on my laptop, and I’m the client so that’s the right place for all the work to be done – why should a central server need to do validation and UI logic on behalf of multiple clients, who can all do it themselves?

The Azure node that served my page is running a single core at 2.1GHz, with less than 2Gb of RAM.  I’m using a relatively well-specced dev laptop, with 4 cores at 2.5GHz and 16Gb of RAM, but I’d say the majority of clients are going to have a better spec than the server. In fact, the next generation mobile phones and tablets are likely to be more powerful than our Web servers.  So we should be pushing as much processing out to the client as possible - they’ve got better kit than we have.

Taking that to the logical conclusion, I’m thinking it’s a valid architectural goal to eliminate server-side processing at the Web layer. Deliver everything in HTML and JavaScript as static files, with an open API behind them which the site and any other consumers can access. No web servers means no state to manage and no load to balance. For remote clients, you just need a file server, so you can host all the web content on something that scales massively and cheaply, like Amazon S3. And to run your web app as a mobile app, you just need to repackage all the static content with Cordova.

It’s a pretty good argument in favour of the SPA approach.

Posted on Sunday, September 8, 2013 8:27 PM The Cloud , Single-Page Apps | Back to top

Comments on this post: The thin client is dead, long live the thin server!

# re: The thin client is dead, long live the thin server!
Requesting Gravatar...
Interesting post. I was wondering what you have on premise vs what you have on the cloud and why?
Left by Cal on Sep 10, 2013 10:04 AM

# re: The thin client is dead, long live the thin server!
Requesting Gravatar...
Hi Cal,

the client has a large on-premise service estate which has grown in and around their core product over the last 8 years.

A lot of those services are tightly coupled to internal representations of the domain, so they have contracts which are not really usable outside the core product (simple example - most entities are versioned, so most GET services ask you for an effective date, which doesn't make sense to external consumers who always want the current version).

We've been putting clean APIs out in the cloud, which effectively VETRO over the existing on-premise services, so external consumers get to use a nice friendly contract, which we map to the internal contract, so we get to re-use all the existing logic.

Left by Elton on Oct 16, 2013 11:08 PM

# Your prediction may be coming true
Requesting Gravatar...
It is taking a while but I think the industry is finally starting to "get it". Maybe it is the accountants who point out how much $$$ companies are spending on hosting, which under the old server-side MVC model is many times more than is should be today. I've worked with some serious CPU/memory hogging server side frameworks and still do from time to time. It is painful to think how much money is being wasted on these outdated systems by way of both hosting and maintenance costs..
Left by Peter Drinnan on Jun 22, 2014 5:41 AM

Your comment:
 (will show your gravatar)

Copyright © Elton Stoneman | Powered by: