Our world is a system. We must understand it to manage. Building a web application is the same, you should know a context to create a system.

Today we will cover a topic that takes a place of honour 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.

Back-end side

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 presenting 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 web-server requires a database.

In most cases, the server and database sit on different computers but have own connection, which ensures higher performance and optimal use of space.

Back end is a system of connected computers that communicate with each other. In real web applications, 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, a notification system to inform the vendor to start preparing the order.

Additional processes

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, processing huge amount 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 tasks 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.

Front-end side

Usually, front-end or client side is easier to conceptualize than a 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 front-end is a client.

An important thing to remember as a non-technical person is that front-end and back-end always come together. When you request a change from a developer, a change will be siloed in both sides.

The connection between 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 behaviour was that 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 application in using newer model, where back-end returns not HTML but data. While front-end is responsible for generating all HTML tags. Usually, web application mix both models, where back-end can respond with 50% of the page in HTML and front-end renders the rest.

Conclusion

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.