Exploring Web Application Architectures, Part 2: Out-of-Band Application Logic

In Part 1 of this series, I described my suggested approach for thinking about web application architecture: start with a static website and add as little as possible until you reach a solution that satisfies your requirements. The rationale behind it is that by nature static websites are cheap, fast, scalable, reliable, and simple — a compelling set of properties — and so serve as an excellent starting point.

The obvious limitation with static websites is that they are static, and web applications, by definition, need to deliver dynamic data generated by some sort of application logic. So how do we add application logic into the mix? The typical answer would be to ditch the static website model, and instead pickup a web application framework like Express that provides full support for plugging-in your application logic to handle HTTP requests. That works, but takes us farther away from our static webserver starting point. Instead of going there, in this post I will explore an alternate approach for hooking-up application logic, which I will call “out-of-band” application logic.

Consider the following diagram:

For the most part it is a standard static website architecture, with static files being served by the web server + CDN — nothing out of the ordinary there. But what I’ve added to the diagram is the application logic, which is used to generate and update the static files (HTML, JSON, images, whatever) served by the web server + CDN . So in other words, we’re going to use our application logic to modify the content that our web server delivers by creating new files and updating existing ones (this may also require notifying the web server/CDN so that it can invalidate cached files).

The key observation here is that we have kept the application logic out of the HTTP request/response flow — in other words, we have out-of-band application logic. This is a bit different from the “traditional” web application framework approach, where the application logic (often organized using MVC or a similar pattern) is an essential part of request processing.

What have we gained by moving the application logic out-of-band? The single biggest benefit is that we have almost entirely retained the properties of the static website approach — we’ve only added a necessary bit of additional complexity and cost, while being able to deliver almost exactly the same performance and scalability. So it is a pretty good deal.

By moving the application logic out-of-band we’ve also eliminated a potential performance optimization headache. If you’ve ever had the “pleasure” of grappling with web application performance problems as you prepare to go into production, you know what I’m talking about. You still might have performance problems if your application logic can’t generate/update the static content fast enough, but that is quite a different problem from ensuring that your application can deliver adequate response times under a heavy load. Using the out-of-band model, as long as you can update the static content quickly enough it doesn’t matter if you’ve got ten visitors an hour or ten million.

Obviously there are limitations with this approach. You do have to be able to update the static content quickly enough to meet your application’s requirements, which can be a challenge if you have rapidly changing data and/or large volumes of it. Or if you have a large number of pages that are only infrequently accessed, you may find that you’re spending a bunch of time generating and updating pages that nobody is looking at, which is a waste. Handling per-user customization of the content is also a challenge — either you generate pages for each individual user (which obviously doesn’t scale well), or you need to explore some different approaches.

Out-of-band application logic isn’t a panacea, but to the extent that you can use it, it is definitely worth thinking about.

And it is important to note that it isn’t an all-or-nothing proposition: you can potentially use out-of-band application logic for some of your application logic, if not for all of it; you can still use the more traditional “in-band” approach when needed. Or you can combine the out-of-band application logic with client-side JavaScript to enable dynamic content in the parts of the page that need it. There are plenty of options.

So if you’re thinking about web application architecture and using a static website as your starting point, considering out-of-band application logic as a first step and seeing how far it can take you might be a useful approach. With a bit of creativity, you may find that it can handle many of your needs. It will likely not yield a complete solution, but the farther it takes you, the better.

In summary, I would offer the following takeaways:

• Don’t reflexively grab a web application framework as your starting point when beginning a new project. They are great tools, but shouldn’t be a limiting factor; consider other options as well.
• Allow for a composite model of application logic organization, where some of your application logic may be out-of-band, some client-side, and some in-band. Expect that your job is to pick an optimal mix of the possible approaches.
• Use out-of-band application logic when possible. It will help you to realizes that very desirable combination of properties that static websites have: cheap, fast, scalable, reliable, and simple.