The Old Days: Static Files & the Request/Response Cycle
Back in The Old Days, we built websites that were mostly for reading text or looking at pictures. Someone's web client sent a request to your web server and it sent static HTML files back as a response. Then we added CSS for style and JavaScript for dynamism. And while websites became increasingly more complex, they remained, primarily, static files sent as a response to an HTTP request. The request identified which set of pre-existing static files to send as a response. This model (each page on a site roughly equates to one .html file that can be 'jazzed up' with CSS and JS) is fairly straightforward and easily held in the mind. It can also be easily explained to people who don't create websites, but want one created. Think of a department manager or business owner. Sadly, that led many people to think, "Building a website is easy!"
Modern Web Apps: Database-Backed Web Sites
The majority of web addresses people type into their browsers are not websites. They're web applications or web apps. But what is a web app and how is it different from a website? In simple terms, most modern web apps are a database of related content with an HTML GUI. The HTML GUI makes the database easily accessible to the intended audience. Amazon is a database of books and various other items for sale. Instagram is a database of pictures. Most blogs are primarily databases of text documents.
The benefit of a database is its ability to store large amounts of information. The problem with a database is getting the specific information you want from it, as well as getting that information in the format you want.
As I said before, these days most websites are web applications. And while the two often look the same, the design and implementation challenges are vastly different.
The Difference: Processing the Request
One of the main ways that a web app differs from a website is that a web app adds an extra step to the request-response cycle that's often overlooked: processing.
Most websites don't need to do much processing. They send a response of HTML/CSS/JavaScript to the client that made the request. That request specifies which documents are desired via a URI with a path to those pre-existing documents. So, https://send.me/this/thing.html where thing.html already exists.
Contrast this with a web app. They frequently get requests that don’t end in a file extension like .html. This request ends in a query string, which begins with the ? character: https://send.me/search?q=thing&SomeOtherStuff. In this case, the app is being asked (queried), "Tell me what you know about thing and SomeOtherStuff and how the two are related." This is where the processing happens. It includes:
- converting the search terms into something useable by the backend software
- forming a valid query to send to the database with those terms
- getting the database response back
- converting that database response into a properly formed HTTP response that can be sent back to the client
While websites have a request/response cycle, web apps almost always have a request/processing/response cycle. That processing step can vary quite a bit in terms of time and resource cost. A lot of it can relate to having to talk to your database and wait for it to respond. Then, multiply that processing cost (in time and resources) by the number of visitors to your web app. It can get out of hand fast.
As an aside, this is one reason static-site generators have made a return to popularity for blogs and many other uses. Depending on your use case, you don't always need a database. As much as we at REVSYS love Django, the Upgrade Django and DjangoCon US sites are both built with SSGs.
Speed and Data Structure
Shortly after starting at REVSYS, I was talking to my co-worker Jeff about best practices when starting a new Django project. He said when working on a new web app (I'm going to paraphrase), he starts by thinking about the data models, or: - What information do you want in the database (what are you trying to keep track of with this app)? - How do those bits of data relate to each other?
When someone goes to a web app, they could be doing multiple things. Most frequently, they're looking for something. But search terms that seem simple to most people ("Chinese restaurant near me" or "1-inch green washi tape") are ONLY simple in a web app if proper consideration has been given to the data models and how they can be queried. When every click is a database query, you want those queries to be as fast as possible. And as your data becomes more complex or increases in volume (imagine the options on a growing fleet of cars or laptops or different models of pens or notebooks), the structure of your data becomes even more important. Beyond the structure of the data (Do you want categories? How many?), the structure of the queries themselves becomes more critical. Writing a nested query may seem to make sense as you step through the logic, but it's almost always a bad idea.
The related issues of query speed and data schemas are things most websites don't have to deal with. But almost every web app has to be designed with this constraint in mind.
Efficiency vs Effectiveness
Slow queries are problematic. They turn off potential users and can use more computing resources, becoming expensive from a time and financial standpoint. But an ineffective query, one that returns a useless result, is just as bad. It doesn't matter how fast it runs if the result has no value. Structuring your data properly helps ensure you can run queries that will return the results people want. I won't name names, but there's at least ONE internet destination whose terrible search function almost ALWAYS disappoints me.😭
Other Things and Remote Control
There are two other issues I want to discuss.
First, more on the processing step. I've focused on database queries, but depending on your web app, there can be a LOT of other things going on. The app could be making API calls to other web apps or software (so each request triggers a new, external request/processing/response cycle). It could be doing all manner of complex calculations on your request or the results of the database query. Anything a desktop app could be doing, a web app could also be doing in that processing step. This is very different from a website, which is usually able to skip the processing step.
Second, let's recall that a web app is a computer application, similar in many ways to a desktop application. But instead of running on your local machine, you're driving it by remote control, over the web. Modern web apps like Google Sheets and Gmail make this look simple (how that happens is an entirely different conversation and beyond the scope of this post), but I assure you, it isn't. Also, most of us don't have Google's resources.
Conclusion
While they look the same, websites and web apps are VERY different things. And with web apps becoming more common, the confusion has only grown.
This is not to say that one is better or worse than the other. But because they look identical from the outside, it's easy to confuse what's needed to build one that works well. There's usually a lot more that goes into designing and building a well-functioning web app than a well-functioning website that primarily delivers static or mildly dynamic content.
Something most web (and desktop application) developers have heard is, "It's just a button!" when someone wants to add something new. The visual representation, the colored shape, is easy. It's making the button function that contains the difficulty. If you click a button, you want a result. That means kicking off a brand new request/processing/response cycle and writing and maintaining the code that does the underlying processing.
