Hate To Break It To You, But The Browser Is A Tier

by Jon Davis 13. August 2010 01:00

“3-tier architecture”. Those words sounded like hogwash to me as I sat in my cubicle 13 years ago, and they still sound the same to me now. The reason for this is mainly because I haven’t ever actually seen a 3-tier architecture. I have only seen 2-tier and n-tier architectures with a mish-mash of strange layers and pseudo-service components.

Before I say anything more, I want to get one thing out of the way. The rough difference between a layer and a tier is that a tier is the physical isolation of software components such that these components can be distributed over the network, for example, to other servers, whereas a layer is a logical grouping of software components such that they are organized in patterns that meet the particular domain of that level or depth of the application (i.e. UI versus business logic versus database, which might be managed via isolated projects or DLLs). If you disagree with what I just said, I suggest that you go Google it for yourself. Tonight I’m somewhat merging the two terms, speaking mainly of physical tiers but also noting that these tiers are logically grouped as layers for practical purposes in most computing situations.

There is a strange belief among some developers and their managers that web servers represent the UI tier (and layer) of a web application. I am not sure where this belief comes from, but I suspect it might have something to do with prior experience with less-mature web technologies where HTML was static and the browsing interface was more of a “dumb terminal” if you will. Lynx and IE2 and Netscape 2. These days, however, web sites can be, and often are—and in my opinion often should be—wholly performing all dynamic view-layer functions within the context of dynamic HTML and AJAX. In my opinion, a “good” web application should be built to execute entirely within the web browser, and the web server should only be used to access data and to perform proprietary business logic or proprietary business algorithms.

Consider for example a web application that consists of nothing but static HTML, Javascript, CSS, and image file resources, plus isolated REST/JSON web services, perhaps on some alternate host. Such a web app can actually be as powerful and as functional as almost any web application these days, including our own which I have to work with every day. In that scenario, the combination of HTML and Javascript act as a client-side workstation application—just like a Windows Forms application or a Visual Basic 6 app of the previous decade—that just happen to be integrating with server resources via web services, those web services being the “proprietary tier and layer for processing shared data”.

By the way, this actually not bad design, architecturally. I’ve heard a lot of whining and complaining from compiled-code developers over the years that Javascript is a crappy kiddie language and should never be used for application logic, but as one who has had more experience with scripting languages than every last one of these whiners as well as on-par experience with strongly typed languages, I am quite convinced that Javascript is an excellent and mature language, one that truly supports most of the fundamentals of OOP and one that is worth betting on for professional web development, particularly if modern browsers are targeted with ECMAScript 5. Unfortunately, it does lack a few things such as design-time/compile-time semantics validation (i.e. no puking at compile-time if you misspell an object’s member reference, as there is no compilation process). But you can certainly unit test against it, that’s why there are frameworks for Javascript like JSUnit, jsunittest, FireUnit, et al, not to mention one unit testing framework I wrote of my own in a previous job. Unfortunately, tooling is still inadequate. It’s difficult, for example, to follow deeply nested “class” declarations and the declarations of their deeply nested members, and it’s true that it’s a bit harder to unit test the view complete with integration tests with Javascript than, say, business objects with C#. It’s still doable, though.

So let’s take this tier breakdown a step further. Microsoft actually implemented HTTP access support in SQL Server since I believe version 2005 if not version 2000 or even 7, alongside the native XML support. It is a poor, insecure practice, but nonetheless fully supported, but you can actually expose this on the front end. Consider then that technically one could create a rich, dynamic web site that had consisted of nothing but static HTML, Javascript, CSS, and image files, and native HTTP access to a SQL Server via SQL Server’s HTTP endpoints. This idea is horrible, but I hope it proves a point. While you will need to either download the HTML+script (etc) files to your hard drive and run them locally, or else make them available via a static HTTP server, this is truly a 2-tier application—one tier in the browser, one tier in SQL Server. Don’t like the idea of downloading the files and running them locally? Take it a step further. HTML and script files stored as database column values within SQL Server, and access them via SQL Server HTTP support. It’s still complete with multi-user support and distributed computing potential (you can rig SQL Server to be in a farm). But it remains a 2-tier application, not 1-tier; the actual execution of CPU cycles to process the application are performed in two distinct places—within the web browser and within SQL Server.

As you tear down the moving parts of a web server, et al, something begins to happen. Everything begins to become blazingly fast. Why? The more end points you have in the life cycle of an application session, the more I/O that must occur, and unpackaging and repackaging, and potential fail points. The more layers you add, the greater the struggle to keep up with the performance requirements and maintenance tasks becomes. Consider the possibility of rich business logic support within SQL Server stored procedures. Imagine all your business logic tucked away in stored procedures. It’s doable, folks, and a number of companies hire application developers who are SQL Server developers first and C# or web developers as an afterthought, where C# code is only used for UI. (I know this because I was interviewed by one such company not too long ago.) Every development team has a completely different perspective of how application development should work. Usually these differences are due to the differences in the business domains. Sometimes, however, the differences are due to variations in management experience (i.e. cluelessness).

One of the applications I work on—I won’t say whether it’s my day job or a side project being co-developed with a friend, or whatever, but let’s just say that tonight as with most of this year since I heard about these circumstances they have had me flabbergasted—is a painful 5-layer, 4-tier architecture, for a small-to-medium sized application. The 5 layers consist of browser UI, server-side app logic, a DAL accessible via WCF web services, CRUD sprocs which are the only means to DB data, and then finally the DB data. (Plus some Windows services, each with multiple tiers.) It just grew this year to 4 tiers because of a belief by a “privacy committee” that the web server, being “accessed by the customer”, needed another layer and tier to sit between the web server and the database where other customers’ data is stored. The application literally could not be migrated to new servers and be given access to the application’s own database until it met this requirement.

I won’t get into how painful it was to inject another tier—the months one developer took just to get the DAL to be proxied via WCF to the isolated web services servers. Nor will I blabber on about the complaining by the leaders who seem to want to blame the developers for wasting time with a server upgrade when there were no performance improvements, while at the same time insisting that this switch to a multi-tier architecture was somehow a good thing for the application. Nor that they had the nerve to keep calling this “3-tier” when it is clearly at least four tiers.

Introducing tiers to a web application is immensely costly to the performance of an app. If n-tier architectures mean “scaling out”, let’s just put it this way: “Scaling out” a legacy application that wasn’t built to scale out is a computer science process that is extremely hard and has no business being mandated by people who are not experienced software developers at their core unless they are willing to let go of at least six to twelve months for a rewrite. The non-leader developers in this case only had the authority and permission to patch the existing codebase in order to meet the requirements—getting the data proxied. In order to correctly build an n-tier, multi-layered application, you have to design much of it as such from the ground up. Most architectures that work best written one way in a two or three tier configuration will not scale well at all in an n-tier setting. And this proves true in this case, as some features in the app I’m referring to now take minutes to perform what used to take a few seconds to perform, because the data must undergo an extra hop via unoptimized XML and the leadership refuses to allow for binary+TCP serialization.

This is my challenge to you, the reader, who for all I know is only myself, it is a challenge nonetheless. Create a rich web application consisting of nothing but static HTML and script. Mock some web services by using static XML or JS(ON) files. Create unit tests for all business and data points. At the end of it all, ask yourself, “Why do I need RoR/ASP.NET/PHP?” I’m sure that the answer will not be, “I don’t,” but the point of this exercise is to prove out the significance and self-dependence of the browser as a tier and the power of client-side application programming for the web. Doing this should actually help, too, with server-side unit testability. Web scripting languages and ASP.NET are prone to be painfully untestable because they really require a browser to render the results before any functionality can be monitored, but if all of the server-side operations have stripped out rendering logic then unit testing the business logic, which is all that’s left, is a cakewalk.

This exercise can also prove out the importance in the value (and pay scale) of strong front-end developers. As one who has sought hard to be strong on all the layers of web development (front-end, middle-tier, and DB), it disgusts me and makes me sick to my stomach when I hear a boss shrug off a resume for being strong on the front-end, or praise a resume for lacking front-end talent. (I am not speaking of my own resume, by the way; let’s just say that I am within earshot of occasional interviews for other teams.) The truth is that every layer and every tier is important and can have equal impact on the success of an application. Leaders need to learn and understand this, as well as the costs and frustrations of adding more of these tiers and layers to an existing architecture.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5



Add comment

(Will show your Gravatar icon)  

  Country flag

  • Comment
  • Preview


Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 

Tag cloud


<<  June 2021  >>

View posts in large calendar