So how do apps work anyway?
We had a look at the definition of a web app in the previous article. However, that doesn’t tell us how all the different parts of the app fit together. This is what we’d call the architecture of the web app. But before we jump into the architecture of a web app let’s start by reviewing simpler architectures.
Standalone apps
In the beginning of home personal computers almost all apps were standalone apps. In other words everything that the app needs is installed on that computer. It doesn’t need to communicate with any other system in order to work. Think of an app such as Microsoft Word running on your computer and saving the documents to your own disk.
Client-server apps
The next app to look at is the basic client-server app. Here the app communicates with a server in order to get information. In the past those servers had to be on the same network as the clients. Think of an email app like Microsoft Outlook running on your computer as the client. This email app would then communicate with a mail server in your office network in order to fetch new emails and to send out emails.
Mobile apps
Now let’s think about a mobile app (we’ll get to web apps in just a minute). Mobile apps work in a similar way to client-server apps. However, instead of running within an office network the client app connects with the server over the Internet.
Communicating over the Internet brings great convenience (you can use your app wherever you are, not just in your office) but also brings along a whole suite of other challenges. In particular we need to think carefully about the security of the whole system. How does the server know that the client is who they say they are and are authorised to access that data? How can the client be sure that all the messages are really coming from the server?
A dynamic website is not a web app
But wait Dave… I’m building a dynamic website which is going to run on my webserver. There isn’t a client, right? Mmm… not quite! There is still a client app here – it’s your browser. But the code for the app doesn’t run on your client device, it runs on the webserver. And as we saw in the previous article a dynamic website doesn’t have as much functionality and access to the client device as a web app.
We still have the same challenges that we have with a mobile app: how does the webserver know that the browser is who they say they are and are authorised? How can the browser be sure that they are connected to the webserver and that no malicious actor is impersonating that webserver?
A web app is like a cross between a mobile app and a dynamic website. Now let’s finally dive into the web app architecture.
Web app architecture
At a high level the web app architecture looks like this:
The browser runs the web app (the client). This then communicates with the back end server, sending over data to get stored and receiving information to show to the user. But now the question is: where does the browser get the code for the web app? And this leads us to the more detailed web app architecture diagram:
As you can see we now have thrown in another server! This webserver gives the browser the web app code. The browser runs this code on the user’s device (the client) which then communicates with the back end server. In theory once the device has downloaded the code it wouldn’t need to constantly stay connected to the webserver. In reality it “caches” the code (stores a copy on the device) and does a quick check to see if the code has changed before running. And of course, this device could be a browser running on a laptop or desktop, or a browser on a mobile device (iOS or Android), etc.
Now that we have seen the basics of the web app architecture, let’s go into more detail in the next article.