Exploring Web Application Architectures, Part 1
Web applications are everywhere and have been the dominant means of delivering functionality to users for a long time. While APIs and mobile apps have become more popular, the web application is still pretty much king and so at some point or another you’re probably going to have to deal with developing one. How to approach web application architecture is the topic I’ll be exploring in this post.
Before diving in, let me clarify what exactly I mean by “web application.” There are a couple of common models for the things that people commonly call web applications. One model is the predominantly client-side,“single-page application” approach used by applications like Gmail, Google Docs, and etc. In these applications, most of the action happens in the user’s browser, driven by JavaScript and using the server mainly for back-end services. The second model is the “server-side” model where application logic resides primarily on the server, which receives requests from the client, executes application logic to generate a response, and then sends that response back to the client. Applications like WordPress and MediaWiki are examples of this model. There are also hybrid models — e.g. “progressive web applications” — that fall somewhere between these two main models. All of these models have their place, and your specific use case will dictate which one is most appropriate.
In this series of posts, I’m going to be focusing on the more “traditional,” server-side WordPress/MediaWiki-style web application and the different architectural approaches you can use to implement them.
But do you really need to sit down and think about web application architecture? Don’t you just pick your platform (Java, Node, etc.) and web application framework (Spring Framework, Express.js, etc.) and then start cranking out models, views, and controllers? Well, you could do that and it would certainly work. If you sit down and think about web application architecture beforehand though, you may find that it helps you to build a better overall solution. I’ll try to demonstrate a thought process that you can use to get there.
If I can first make a brief aside: Michelangelo is reputed to have said something to the effect of, “to carve a statue, start with a block of stone and chip away anything that doesn’t look like what you’re trying to create” — a subtractive process. The approach that I like to take when thinking about web application architecture is sort of the inverse of that process: begin with a minimal starting point, and add to it until you’ve arrived at a suitable solution — an additive process.
More specifically:
To architect a web application, start with a static website as your model and add as little as possible to it until you reach a solution that satisfies your requirements
Why would I recommend using a static website as your starting point? Static web sites lack the ability to generate dynamic content, so why bother with them? What do they have to offer?
Well, consider the properties of a static website deployed on a capable web server like Apache or Nginx — or even more interestingly, consider the properties of the same thing paired with a good Content Distribution Network (CDN). It may not deliver dynamic content, but it is:
- Simple — configuring a web server properly can be a challenge, but from an overall systems perspective the static website is very straighforward
- Efficient — it is tough to beat the price/performance ratio of delivering web content via a web server + CDN
- Performant — you can’t get much better performance than from a CDN-based static website, worldwide
- Scalable — you can handle just about any amount of traffic
- Robust — it is unlikely that your website will get knocked out entirely (but as we’ve seen recently, you can have problems)
So the humble static web site is cheap, fast, scalable, reliable, and simple. That’s a pretty killer set of attributes. And it is a pretty good reason to think about static websites when considering web application architecture. The more you can capture that combination of properties in your web application architecture, the better off you’ll be.
Using a static website as the starting point for your web application architecture may sound a bit unorthodox, but there is some precedent for it. The thinking behind REST APIs, for example, was motivated by trying to implement dynamic APIs that realize many of the benefits that HTTP offers— effectively taking HTTP as a starting point and using that to guide the creation of an API for accessing dynamic data. When you find something that works, run with it. And HTTP works.
But how do you actually go about creating a web architecture starting from a static web site? In subsequent posts (which I will add links to below) I’ll explore some different approaches you can use.
Postscript: Additional articles in this series include:
