A Developer’s Guide to Web Application Architecture

Kumar Harsh  on October 12, 2021

The internet has evolved from static web pages and long loading times to super-fast progressive web applications that can install themselves on client devices. The focus of web applications shifted from providing content to offering a captivating experience. As more and more people join the internet, the demand for visually appealing and friction-free web applications continues to grow.

A web application is similar to a standard desktop or mobile application except that it can run on a web browser. Such apps hold immense growth potential since nearly all computing devices support accessing the web using a browser. However, due to its vast nature, it is impossible to create the perfect web application in all cases.

Feel free to use these links to navigate the guide:

What is Web Application Architecture

The web application architecture is a blueprint or a skeleton that charts the interactions between various application components, middleware systems, user interfaces, and data stores. The whole ecosystem, with persistent communication, enables multiple applications to work together and provide services to the end-users.

Why Does it Matter?

Web application architecture is the first stage of the web software development process, making it the backbone of your application. This, in turn, puts forth a number of reasons why it is important to focus on the architecture of your web application.

First of all, the architecture that you choose is the foundation of your product development process. Each component that you build for your software will be based on this initial design. If the design is robust and fault-tolerant, the product that you build will also be the same. If your design is poorly thought-out, it will affect all the stages of the application development process and will cost you both time and money.

Secondly, web application architecture is quite difficult to modify or change in the later stages of the application development process. If you try to introduce major changes in the design at a later stage, it would require you to break down and rebuild the complete product from scratch, affecting your application’s release data and incurring financial losses to the project.

Thirdly, a bad web application architecture can prove costly when your application enters the maintenance stage. Making changes or updates in a poorly designed app is difficult. More often than not, you will face the dilemma of making lengthy changes or restructuring your entire app from scratch.

While it’s natural to be unable to foresee every possibility while designing an application, your goal should be to make the best guesses. The requirements of your software product might change very fast; hence flexibility should be an essential aspect of your web application architecture.

How Web Application Architecture Works in a Nutshell

undefined
The Complete Web Application Architecture. Source: Google

Web application architecture is a joy to watch in action. The above diagram lists the various parts of a web application architecture in depth. However, developers don’t use all the components in their web applications. A typical web application workflow looks like this:

Key Differences Between Software Architecture and Software Design

Software architecture and software design are often confused. They are, in fact, two entirely different concepts. Let’s take a moment to contrast the two before we move ahead with our topic.

Software architecture is the skeleton of a software application system, as mentioned earlier. It defines how the various high-level components of a software application system interact with each other. It’s all about the big picture of your application, the “what” and “where” of the things that make up your web app. 

The central aim of software architecture is to identify both functional and non-functional requirements of a software product and handle them well to enhance the end-users’ overall experience.

Software design is more about the code-level design of your application. It is responsible for the functionality and quality of each code module. It aims to answer the “how” of your application and its codebase. It always comes after the software architecture is ready.

Software designers think in terms of functions, classes, interfaces, etc., when designing an application. This provides programmers with an efficient common language to find solutions for repeated programming issues and conceptualize them. It helps the back-end and the front-end team stay on the same page using a set of pre-defined specifications.

Frontend vs. Backend Application Architecture

The type of design that they rely on to offer the end-product to their users plays a huge role in web application architecture. The two prominent categories in this classification are front-end and back-end applications. Let’s take a look at these in detail.

Front-end

Front-end refers to applications that run on client devices and use minimal support from in-house servers or the cloud. These are often standalone applications that do not need to use a lot of shared data or carry out heavy computations. However, such applications are not entirely aloof from the back-end servers and often require a small web server to support their operations.

Single Page Applications

Single Page Applications or SPAs run as self-sufficient applications on client devices. These applications do not load themselves again and again on the client, similar to static websites. Instead, they keep an open connection with their remote server, which keeps sending them new data as needed. The SPA on the client device updates itself automatically based on the incoming data.

The SPA architecture is helpful in applications that do not depend heavily on frequent network transactions. SPAs help to deliver a great user experience as they look and behave just like any other standard native application on the client device. JavaScript is one of the most popular languages used to build single-page applications.

With the single-page application architecture, it can become challenging to optimize your app for search engines. This is because the app generates content dynamically every time a user requests for it, and it’s not generated beforehand for the search engine crawlers to access. Also, crawling dynamic URLs of such SPAs is difficult. As such, resources usually depend entirely on real-user interaction.

Server-Side Rendered Applications

Server-Side Rendering is the process of pre-rendering an application’s final webpages in a server environment and sending down this pre-rendered HTML, CSS, and JS code to the client browser. Since rendering web content now occurs in a much more powerful server environment than the users’ client devices, its speed increases greatly. It is possible to deliver the content very fast to the users.

Server-side rendered applications do very little initial processing on client browsers. The generation of HTML and CSS code, usually by using the JS code on the client in SPAs, is already done on the server, so the browser can simply paint the UI as soon as it receives the HTML and CSS for the application. This removes the dependence on receiving and processing JavaScript on the client, speeding up the process.

Server-side rendered applications are useful in situations where you need to show a lot of varied content in your application which might come from a large number of sources. Instead of your app loading on the client and then making multiple network calls for the complete data, you can pre-populate the page with the data on the server and then send it down. SSR apps are great with search engine optimization, but they are more vulnerable to security breaches than single-page applications. Also, SSR apps require a server to function, and page transitions are slower than SPAs.

Back-end

Back-end refers to applications that function entirely on the underlying technical infrastructure of the business and rarely come into contact with the end-users. Back-end applications often complete routine jobs or offer support to other front-end applications in providing a service to the users.

Microservices

Microservices is a type of web application architecture that relies heavily on composition and reusability. Microservices architecture deals with small and lightweight services that are focused on executing a single functionality. This type of architecture is efficient to develop and maintain. These services can be reused in other applications easily since they are entirely independent.

Apart from being independent of each other, these microservices are also language-independent, meaning that two microservices can be written in two different programming languages and still integrate perfectly with each other. This gives the developers an additional level of flexibility as they do not have to stick to the same language runtime every time.

The downside to this architecture is that inter-service communication is essential and needs to be highly reliable and secure. Debugging is another issue, as each microservice has its own monitoring lifecycle and log dumps. A significant pain point in microservices is integration testing一since the components aren’t all together, it is difficult to test an entire system from individual machines.

Serverless Architecture

Serverless architecture is one of the hottest web application architectures in the current market. This popularity is because serverless helps businesses cut down on their server costs and helps to focus the development team’s efforts towards the code and not the whole infrastructure. In serverless architecture, the application does not work on traditional servers; instead, it executes the modular functions on a remote server provided by the cloud provider.

This means that you only need to focus on writing a function that will execute whenever your app receives a request. The underlying server and its management are handled by the cloud provider, helping to create modular applications quickly. Also, scaling serverless applications is easy since you do not need to worry about provisioning more servers; your cloud provider handles it for you.

Web Application Architecture Models

There are three major monolithic models of web architecture, based on the number of servers and databases present in the web application design.

One Web Server, One Database

This is the simplest model of all three; there is only one web server and one database. Such a model is highly unreliable, as the failure of any among the web server and the database can result in the entire application architecture going down. 

Such a web architecture model doesn’t translate well to a production environment. It is too unreliable to run business-oriented applications. It does come in handy when trying or testing new applications because architecture reliability is not of high priority during the testing phase. Setting up such an architecture is fast and easy, so testers can quickly deploy and redeploy their web applications and run tests.

Apart from testing, this model finds its use in the learning phase of a software developer. Since setting up a one web server, one database model is fast, easy, and cheap. A learner can quickly create and destroy such web applications and learn the fundamentals of web application development.

Many Web Servers, One Database

In this model, multiple web servers rely on the same database. Due to multiple servers accessing the same database simultaneously, it is risky to allow them to retain and maintain their own states. Hence the web servers in this model are entirely stateless, meaning that they do not retain any data from their client-server sessions unless it is in the database. Whenever a web server receives any important data from the user, it either stores it in the database or erases it when the session is closed. 

This model requires at least two web servers. The reason for having more than one server is to make the system fault-tolerant. If one of the web servers goes down, the other one continues to function and provide the service, making this architecture style more reliable.

However, if the single common database crashes, application availability is disrupted. Therefore, there are still chances of the application going down unexpectedly in a minor crash in the database.

Many Web Servers, Many Databases

Out of the three web architecture models, this model is the most efficient and reliable because it does not depend on any singular resource unit that may cause unexpected disruptions in the operations. Aside from multiple web servers to increase redundancy, this architecture model provisions multiple databases. You can either maintain copies of the same data in various databases or distribute your complete data into multiple smaller chunks stored across various databases. In either case, you are bound to increase the fault tolerance of your web application.

In the first case, two databases are usually sufficient. For the second case, you might need more databases based on your data size. However, in the event of a crash, a part of your database might be inaccessible in the second case, while the complete database will continue to be available in the first case. Both cases utilize DBMS normalization.

If your web application architecture uses many web servers (read five or more), most developers recommend using load balancers. Load balancers help distribute and divert traffic to multiple web server instances, thereby reducing the load from one web server instance and preventing it from overloading.

The above-mentioned three models are monolithic in nature, meaning that they couple databases and servers tightly in one unit. However, application service models tend to perform better in most cases (microservices and serverless models) since they decouple resources and simplify the process of updating and scaling. These models split the application into multiple parts (multiple services in microservices and functions in serverless). This makes scaling and deploying easier than the traditional monolithic models.

Web Application Components

It’s time to dive into the components of the web application architecture and understand the various components that make up our modern web applications.

DNS

DNS stands for Domain Name System, and it acts like a phone book for the internet. It allows entities to search for web-based resources using domain names and IP addresses. Whenever you type a website name in your browser’s URL bar, say scoutapm.com, the request goes through the DNS, which locates and retrieves the IP address of the web resource associated with scoutapm.com, which is essentially a webpage.

The use of DNS is not limited to just websites. The web ecosystem can also house resources such as images, files, etc., which are known as web resources. These are also located on the internet using an IP address that can match with human readable URLs. 

Load Balancer

Load Balancers are entities that help efficiently distribute network or application traffic across multiple servers in a system. A load balancer situates between client devices and backend servers, and it catches all of the incoming requests before they hit the servers. Once it receives a request, it determines to which server to pass it forward.

We call load balancers entities because they can be anything, ranging from physical devices, virtualized processes running or special hardware, or a dedicated software process in the mainframe that houses web servers. Load balancers utilize various load balancing algorithms to distribute the incoming traffic according to the current requirements and server availability.

Web App Servers

Web app servers are the main brains behind the whole setup of web applications. Web app servers handle the actual request sent by the client, process it to receive any incoming data, query the database and other resources if needed, and return the response to the request back to the client. There is usually more than one web server in modern web applications, and the load balancer distributes the incoming requests between the available servers.

Web servers can be classified into two major categories一concurrent and iterative. Iterative servers are designed to handle requests one by one and consume fewer resources, while concurrent servers can spawn new instances of themselves to handle a sizeable incoming load.

Databases

The database is where the web applications store all of their useful data. The emphasis on usefulness is because an application generates a lot of data over time. But not all of this data is useful to the stakeholders of the application. An application might generate intermediate data that may not hold any importance to the users. Such data is usually in caches or local memory for as long as necessary.

Databases can support the most basic operations on the data. That includes searching, sorting, fetching, updating, adding, deleting, etc. An application can use these functionalities to implement any type of operation or manipulation of the data.

Caching Service

Caching services help to provide a short yet fast storage for users to load web application data. If your users visit a webpage, it is stored in the caching service for a while so that if they try to visit the webpage again, they may be able to get there faster. The use of caching services varies based on the type of web application that you are developing. Static web pages are almost always cached to support fast retrieval, while PWAs are rarely cached to allow users to get the latest version of the app easily.

Caching is a highly effective measure to counter slow & frequent computations. Also, if a request returns the same result repeatedly, caching the result can increase the ease of access for the users and provide them with a better experience.

Job Queue

The job queue is an optional component of the web application architecture, and it houses two components: the queue itself and web servers. These servers are responsible for working on jobs that are of low importance and can be processed asynchronously. Not all applications need such servers, which is why this component is optional.

The queue maintains a list of jobs that have to be processed, and these jobs go to the servers based on the job schedule and server availability. In many cases, jobs are run in batches to save on processing power and time.

Full-Text Search Service

The Full-Text Search Service is another important yet optional component of the modern web application architecture. The purpose of this component is to allow users to search through an application using keywords. This component is highly useful in applications like social media platforms, where searching and retrieving are important.

However, in utility apps like calculator, converter, etc., a search functionality does not make sense, which is why this component is optional. Many applications choose to build and integrate this functionality in their business logic, but it makes much more sense to maintain a dedicated search service, especially in large applications.

Services

Services are independent sections of a web application that may or may not be in use during every user journey through your app. The services segment of a web application usually comes into existence when it grows large in size. However, some applications form in the way of multiple services integrated together. 

Services come in handy in situations where a single app must do a variety of jobs. Maintaining the business logic of all of these functionalities in the same codebase can be tricky and difficult to test. Separating these in the form of services with their own life cycles makes coding and maintaining them easier.

Data Warehouse

After some time, almost every application generates more data than it needs to handle in real-time. Over time, a lot of data slowly goes out of use but is still necessary to be preserved for historical reference in the future. This is where the data warehouse comes in.

The data warehouse is a medium for storing large amounts of data for a long time. The key here is not to put hot data in warehouses, just data that a team rarely has to access. 

CDN

CDN stands for Content Delivery Network. CDN systems help distribute content such as HTML files, CSS files, JS files, images, and other types of files to the end-users scattered worldwide. While a usual server can still deliver these contents across the world, the time taken for a server to deliver an image to the other side of the globe can be pretty long. CDN solves this problem by caching these contents in its data centers all across the world.

While it’s not usually necessary to put normal file contents such as HTML files, images, etc. through a CDN, heavier content such as videos and streams need to be distributed through a CDN for a good real-time experience for the end-users. 

Layers of Web Application Architecture

The web application architecture is composed of various layers which have their own purpose and design. When stacked on top of one another, each of these layers helps deploy a web application to the users. Let’s take a look at these layers in depth.

Presentation Layer

The presentation layer is directly visible to the users in their browsers. It consists of user interface elements and user journey components that allow interaction with the application and its system. 

The presentation layer also can modify or customize the interface to each user on the fly, based on the user’s profile. This means that even though multiple users are accessing the same application, they might view different interfaces based on their historic usage patterns. This is an important part of an application’s presentation to its users since it adds an extra touch of personalization to the user experience.

Software engineers develop the presentation layer using three fundamental technologies: HTML, CSS, and JavaScript. HTML determines what your interface will contain, CSS controls how your interface will appear, and JavaScript controls how your interface will behave when users interact with it. Many frameworks help build these interfaces faster, but at their core, they all compile down to HTML, CSS, and JS for web applications.

Business Logic Layer

The Business Logic Layer, also known as Domain Logic Layer or Application Layer, accepts user requests from the client browser, processes them, and then determines the route through which the request will access application data. The data and requests travel through workflows encoded in the business layer. To understand this better, you can consider the example of a train ticket booking website. The business logic behind searching for trains and booking seats based on availability rests in this layer.

This layer exists because there is more to an application than merely searching and fetching. There is additional logic, such as checking the availability of seats in our previous example. This logic has to be defined and used in the app, and it has to be kept secure at the same time. Therefore, it makes sense to abstract the logic from the presentation layer into a separate dedicated layer, making it easy to update and maintain the application’s business logic.

Data Access Layer

The data access layer, also known as the storage or persistence layer, is a centralized location in the web application architecture that receives all data-related calls and facilitates access to the persistent storage of a web application. This layer is closely connected to the business layer since the business layer has to make frequent calls to the database to carry out data-related operations.

This layer’s infrastructure contains a server and a database, some software to communicate with the database itself, and some user interfaces to obtain and visualize data from the databases. Usually, you can store your data on your own hardware or the cloud (by purchasing data center management and maintenance services while accessing your storage virtually through the internet). 

Premier cloud providers such as Amazon, Google, and Microsoft offer IaaS (Infrastructure-as-a-Service) technologies to help you set up your data access layer online and facilitate data storage and manipulation in your web application.

Data Service Layer

The data service layer’s main job is to transmit the data processed by the business logic layer to the presentation layer. This layer ensures that the data sent from the BLL to the PL is secure and unaltered. It provides a consistent interface (known as the data service facade) for accessing data, independent of the underlying object-relational mapping framework used.

After the data transmission is complete, the underlying mapping framework transforms the retrieved data into a collection of objects that can be interpreted by the language runtime, say Java. These objects implement as physical Service Data Objects (SDOs). The data service layer helps to perform transformations between and operations of physical and logical SDOs.

Web Application Architecture Best Practices

Now that you understand web application architecture in all its glory, it is time to look at some of the best practices and tips you must keep in mind to build a robust architecture for your next web application. Evaluating the quality of a web application from outside without knowing its complete architecture is difficult. The best way to judge the application’s design is to check if the architecture helped achieve the goals set for the application and the business.

There are a few parameters that you can watch to make sure that your application is on the right path towards success. The parameters include:

Apart from keeping an eye on these parameters, you need to strive to maintain a high level of performance in your end product. To do this, you might need to refine the way data travels in your application and take into consideration the locations of your server and your target user base. To learn these fine things better, you might want to look at the pioneers in the various types of web applications in the market right now. Some of them are:

While taking care of all this is important, it is equally important to understand that each web application is unique. Therefore what worked for some of these giants may not necessarily work for you. You need to assess your needs and goals before comparing your performance to other standard applications’ performance.

Looking Ahead

The modern web application architecture is continuously evolving, similar to other modern technologies like the Internet. The first web app architecture appeared during the time of Web 1.0. With the advent of Web 2.0 and 3.0, it observed a great increase in its value and importance in the web application development process. 

Deciding on the best web application architecture for your application is a key stage in its development. The model and type of architecture you choose can greatly impact a web application’s robustness, responsiveness, usefulness, reliability, etc. If you make any mistakes in this step, it can be very costly to your business, and it can even lead to a significant delay in the release timeline of your digital product. This delay can directly translate to budget losses.

If you are looking for a robust monitoring solution for your web application, make sure to check out Scout. Pro tip: try Scout for free for 14-days to see the difference it makes in your monitoring game before deciding.