Architectural Drivers

My apologies to the reader if this sounds obvious.

Application software is now delivered over the Internet.  An extreme type of software delivery is the web-application. One points a browser at a web-site, Javascript is downloaded as it is needed and the application runs.  This type of delivery is quite popular for the following reasons:

• The software supplier is dealing with a single version of the code.  Bug fixes and enhancements are immediately available to all customers.  Support is greatly simplified.
• The software is not stored on the user's computer. You have to access the server each time you use it.  This is basically what enables the entire SaaS business model.
• There aren't that many client machine architectures, i.e. browsers.  It may be a bit ugly but it is not as bad as needing to compile a new binary for each machine.  Technology is not getting in the way of addressable market.

Application delivery times are pretty much a function of the application size and bandwidth.  Somewhat interesting, mobile applications operate in world where repeated downloads of large applications are both slow and expensive.  One installs a client application on a mobile device to minimize both application start time as well as the cost of bandwidth.

The ramification is that what is valued in a web-application is different from what is valued in a mobile application.  This results in fundamentally different technical approaches.  Someday they may be harmonized but that day isn't today.

Since a web-application is download-when-needed, the part that is downloaded to the client is mostly concerned with the user interface.  Server response times (latency) aren't fast enough to run highly interactive UI's over a network.  That work gets done in the client.

Some consequences:

• People try to minimize the amount of code downloaded.  You'll see people publish stats on the size of their Javascript library as the size impacts page-load times.
• One minimizes the amount code downloaded by not putting things there you don't immediately need
• Focus on UI, leave business and domain logic on the server
• Within the UI, focus on interactive UI and leave static presentation on the server.
• Javascript libraries become page-specific.  Yes, the wheel of reincarnation has spun and we are managing our own overlays.
• The server has multiple roles and functions.  It not only has to deal with business and domain logic, it is also implementing portions of the presentation layer.  The server portion of the presentation layer is typically implemented using a templating system.

Most of the development frameworks out there miss this fundamental truth.  Languages like PHP are great at templating but don't help at all with Javascript.  It seems that other frameworks (e.g. Rails, Microsoft's Razor) try too hard to use "just one programming language" and neglect highly-interactive UI's as those UI"s need Javascript.

Informal History

I really became aware of applications with GUI's when I first used one of the original Apple Lisa's.  In the early 80's, I was lucky enough to work at a company that had one and I got to use it. A little while later the Lisa was followed by the Macintosh.  Apple allowed people to write code for the Mac and there was a wonderful series of 3 books named "Inside Macintosh" that explained how things worked.

The first Mac's had no memory management unit, so everything used Handles to allow storage to be reclaimed.  And with no MMU, threading was a programming convention.  Just like Javascript today, the application was single-threaded and used an event loop.

But what was really fascinating was the conceptualization and clarity of the UI component framework.  Menus, windows, labels, buttons, etc. were all there.  I'm not sure if Apple was the first to do things this way but they were the first to teach it to me.

30 years have gone by since then but not much has changed in the approach to UI frameworks over those years.  We've had Windows Forms, X-Windows and Java Swing in that period as well.  All have much in common with the framework organization found in the Mac.

Lately we've heard about thin-clients, web-apps, mobile apps, etc.  X-Windows was designed for thin clients.  People even sold X-windows terminals.

Anyone remember Java WebStart?  It was a way of downloading and launching a thick-client Java application from a web-site.

The web has evolved but it never really had a true Web 2.0 version.  Changes were done incrementally.  The key non-change is that what is shown on the screen is what is in the DOM.

What has struck me about today's web application technology is that how much has remained the same with a few critical differences:

• The thin-client now runs in a web-browser and its native graphics abilities are relatively awful
• Server-side processing (what used to be done in worker threads) cannot easily notify the presentation layer that the model has changed.  The client has pull and poll to get anywhere
• Bandwidth and communication latency are important.  Bandwidth is somewhat related to total information transferred (cost factor for mobile devices).

In my next blogs, I'll look at how these differences are shaping our current architectures.

Introduction

I'm interested in Web Application Architecture as it is a technically challenging subject which entirely subjective.  There are a lot of different answers, depending on what you'd like to do.

When I'm reading the literature or looking on the web, I don't see very many good discussions on this topic.  So I'm taking a run at this topic by starting this blog.

There is a lot of work going on.  Ruby-on-Rails, Microsoft's MVC, PHP, etc.  All seem to address a part of the problem but don't address the larger design problem as their tools are not as broad as one would like.