Our world is a system. We must understand it to manage. Building a web application is the same, you should know the context to create a system.
Today we will cover a topic that takes a place of honor in software development – web application architecture. The article aims to help non-technical people better understand the technical side of the business and improve communication with developers. The piece is not too technical, thus catering to a wider audience. Remind you that we already uncovered topics dedicated to choosing tech stack for a startup, front-end framework and backend frameworks.
Web application architecture in details
Everyone has a basic mental picture of how web application architecture works. Front-end application hits back-end application, which sends the database a request and does business logic whereafter returns a response to a front-end.
We strive to take this picture and decompose it into components. The article is divided into four parts for a better understanding. The first part uncovers back-end and front-end sides of the architecture. Then we will tie them together with basic use cases and discover additional architecture components.
The Server-side (back-end) is an application or set of applications connected to the Internet or cloud. The general gist here – to service requests. Two common components define the back-end side: web servers and databases.
A web server is easy to understand, but also easy to overcomplicate. The web server process is anything that responds to an HTTP request and returns a file to it. With the web server, the developer can create a static page that does nothing except present information.
The second back-end part is a database, every semi-intelligent web server leverages a database that persists something. The database is not necessarily related to web technologies. For example, hospitals stores doctors’ and patients’ data in a file system. This is an offline database. Not every database needs a web server, but 99% of the projects with a web server require a database.
In most cases, the server and database sit on different computers but have their own connection, which ensures higher performance and optimal use of space.
The back end is a system of connected computers that communicate with each other. In real web applications, the back-end is not limited to web server and database. There are more than 30 processes that run on the back-end of an application. If you press “Buy” on Etsy, it hits not only web server and database but 50 computers processing your request. It hits payment, inventory system, security system, and a notification system to inform the vendor to start preparing the order.
In this section, we will cover other back-end processes, like background processing and caching. A background process is when you need more time to process a request. The webpage is quick, but sometimes it takes longer to process. Background processing eliminates the user’s waiting time. It handles things that take a physically longer amount of time, like numbers crunching, and processing huge amounts of data.
The second process is caching, in the most basic use case you get a request from the web server and it hits the database, which response. Although, hitting a database can be expensive task and especially when the same request goes 100 times. You may wanna cache the response to respond faster to the client. Remember the basic idea of the cache – faster and easier access for things that happen often.
Your sofa with the jacket on it is the cache for your closet or the bookshelf is the cache for the library. Managing caches is the most challenging part of software engineering, but it’s also a pervasive part.
Usually, the front-end or client-side is easier to conceptualize than the back-end. Front-end is any type of code that runs on the client’s side. The client, for example, includes the Chrome browser used to watch a video.
The main premise of the Internet is a client-server relationship, where clients making requests to a server. Let’s illustrate web application architecture using ordinary offline actions. Imagine that you go to the steakhouse and order a steak. You are the client and the restaurant is the server. You order a steak and the restaurant responds with a meal. All back-end is the restaurant and the front-end is a client.
An important thing to remember as a non-technical person is that the front-end and back-end always come together. When you request a change from a developer, a change will be siloed on both sides.
The connection between the back-end and front-end
Section four will tie all the stuff together. So, come back to the basic model: front-end application is something we interact with and it makes requests to the back-end processes.
The older way of web app application behavior was that the back-end would render the entire HTML and return it back to the front-end, which displayed the data. All the HTML rendered on the back-end it’s returned in the response. All the browser has to do is display it.
Now many applications in using a newer model, where the back-end returns not HTML but data. While the front-end is responsible for generating all HTML tags. Usually, web applications mix both models, where the back-end can respond with 50% of the page in HTML and the front-end renders the rest.
We talked about back-end and front-end responsibilities and how they can be mixed and matched. But as a non-tech, you shouldn’t think of all the tech you are working with as a magical black box. The best thing you can do to empower your communication with developers is really understood what responsibilities are for different parts of the technical system.
If you have further questions regarding web application architecture, our CTO can help. Please contact us in order to get a free consultation.