Web application architecture is a key reason why some web apps are underperforming while others run smoothly. It’s because architecture defines how different software components interact with each other and the end-user.
In this article, we’ll tell you everything we, at Acropolium since 2003, know on the topic of building “unicorn” apps using the right web app architecture.
- In this article, we’ll explain how web applications work and how the right architecture improves their performance.
- We’ll also let you in on the latest practices that can help you during web development.
But before that, let’s make sure we’re on the same page.
What is web application architecture?
Web application architecture is a framework for relationships between the client-side (frontend) and server-side (backend) components of a web application. Simply speaking, architecture outlines how the elements of an app will work together.
Let’s take a brief detour to lay the basic terms. A web application is a piece of software that’s accessible through a web browser. Unlike a website (a collection of static pages with text, images, audio, and video), a web app allows users to interact with its elements and manipulate content. Gmail, YouTube, Facebook, and Twitter are excellent examples of dynamic web apps.
Before discussing the importance of web app architecture design for development, we should explain what makes up a web application.
Components of web application architecture infrastructure
Every application (web, desktop, or mobile app) has two sides: frontend and backend.
- Frontend (client-side) — a code that runs in the user’s web browser or interface. This is the part of the app that the user sees and interacts with.
- Backend (server-side) — servers, databases, and application logic that run behind the curtain. Backend components store data, process requests, deliver the information you see in the app.
Let’s talk about the elements of the web-based application architecture and their functions.
The content of the web page includes:
- HTML (HyperText Markup Language) — defines the content and structure of the webpage.
- CSS (Cascading Style Sheets) — specifies the styling (text size, color, and font) and presentation of the page (separates the content and layout).
Web servers are computers that accept requests, process them, and send the data to the user’s browser.
The term “server” applies to any computer that provides services over the internet (or private network). Servers fall into different categories based on the type of services that run on them. For instance, web servers process HTTP (port 80) and HTTPS (port 443) requests.
Database servers are centralized locations for databases (organized collections of information). These servers communicate with web servers and provide data to authorized users.
The domain name system (DNS) is an internet-based hierarchical naming system that translates a domain name (like www.google.com) into an IP address (126.96.36.199).
Browsers need IP addresses to communicate with web servers. DNS simply helps users connect using readable names instead of complex numbers. You can think of DNS as the contact directory for the internet.
Web applications can consist of multiple services hosted across several servers. Messaging middleware helps different software modules, programming languages, and applications communicate.
The client-side and server-side of the web app interact using synchronous (HTTPS and TCP) protocols, whereas server-side components of the app could also use asynchronous (AMQP) communication protocol. Plus, middleware software and application programming interfaces (APIs) bridges data between applications and servers.
Every server has limited RAM and CPU, so more user traffic can result in performance issues. Enter load balancers.
A load balancer processes traffic and distributes it across web servers based on the available computational resources. This optimizes the load, allowing the web app to run smoothly.
The cache is a temporary medium that stores web page data and delivers it faster upon repeated requests.
In the web app server architecture, caching usually happens in the browser. For instance, when you first load a web page, parts of it are saved in your local storage. Then, when you reload the page, the browser gets these files directly from the cache (without contacting the web server).
Imagine a user from California accessing a web app in a data center in New York. The browser can fetch information from the data center, but the page will take longer to load because of the distance. Now, let’s say a web app utilizes a CDN in California. Then, the browser can download the heavy files from a nearby node much faster.
So, it’s time to tell you how all these components work together when someone interacts with a web app.
How modern web applications work
Now that you’re familiar with the terminology, we can show you what happens when a user enters a URL in the address bar.
- The client (browser) contacts a DNS server, which provides the IP address.
- The browser then sends a request for web documents (JSON, HTML, and others) to the web server.
- The web server forwards the requests to the application logic (business layer of the app), which determines the course of action depending on the user’s access level and type of request.
- If the request meets the access criteria, the app logic loads data from the database and sends them to the browser.
- The browser renders the information and displays it as a website page.
All these processes take place on different layers (tiers) of the web application. And this brings us to the next topic.
Layers of web application architecture
The infrastructure of a web app consists of three isolated layers, namely the presentation, business, and persistence layers. Here’s what they are responsible for.
The presentation level is the frontend of the web application located in your browser. This tier renders data from the backend into readable content and interface elements.
When a user interacts with a web interface, the presentation layer sends a request to the business layer.
The business layer (application logic tier) is the part of the backend that determines the internal logic and rules. It contains the application code that coordinates all processes in the app. This tier also transfers the data between the presentation and persistence layers.
The persistence layer (data tier) is a data server of the web application that collects, stores, and retrieves data (files, logic, website settings, confidential, and user-created information). As you’ve learned, the persistence tier sends data to the business layer upon request.
Here’s how the layers work together:
- The user interacts with the presentation layer via a browser.
- The presentation layer sends requests to the business logic tier.
- The latter evaluates these requests and communicates with the persistence tier to retrieve the necessary data.
- The business layer routes the data to the presentation layer.
- The presentation layer delivers the data to the user via a web browser.
At this point, you should already have a clear picture of the whole technology layout. Time to figure out how to choose the architecture for your web application.
Read also: SaaS infrastructure architecture best practices.
Types of web application architecture
As we mentioned, the architecture defines the high-level dependencies between the frontend and the backend components. So, we’ll describe the common types of modern architectures separately for the client and server sides of the app.
Server-side rendered application (traditional)
In the server-side rendered (SSR) architecture, the web server generates the whole page on every request. This means the browser must reload after every time there’s a need to update the page. While it’s great when render times are low, the UX can go south if it takes too long.
The single-page application (SPA) is a modern web application architecture that serves web pages with dynamically updated content. Here’s how the process goes:
The SPA architecture allows the web app to dynamically rewrite the page content without reloading the page. Because of that, the user experience becomes dynamic, and requests become less resource-demanding for the backend.
Progressive web application
- Web manifests (JSON files with metadata)
- Service workers (APIs that bridge app, browser, and network)
Service workers connect users to the backend and cache the app data in the background, allowing the web app to be available even offline.
Microservice architecture implies that the backend of the app is split up into multiple single-purpose loosely coupled services. These services run separately, communicate via a network, and scale independently. In addition, microservices communicate synchronously (RESTful API, TCP) or asynchronously (messaging).
For example, an online shop may have microservices for customer registration, file uploading, user interface, product catalog, cart, and payment process.
Here’s what makes the isolated structure of this architecture appealing:
- Microservice can be built independently by different teams, improving the development speed
- The code or tech stack for each service can be changed without impacting the whole app, so you can test different parts of the system
- Services can be added to the app at any stage of the application’s life cycle
This architecture has some drawbacks, though. Resilience testing and monitoring are challenging because you have to work with separate modules across multiple servers. On top of that, your team has to document communications between every microservice.
Serverless solutions can boast several advantages:
- The provider takes care of the hardware and software management, allowing your team to focus on building and managing your application
- You can quickly scale the infrastructure up and down based on your needs
- Most serverless plans have a flexible billing model, so you only pay for the resources and storage you use
The infrastructure security and available resources depend on the third-party vendor, which might concern some enterprises (FinTech and healthcare come to mind). However, you can opt for advanced subscription plans and tenant isolation models with advanced authentication and isolated databases.
Phew, that was intense. But now, it’s time to point out that designing a dynamic web application is not just about choosing the architecture. It’s also about knowledge of the development approaches and ways to apply them to your project.
Read also: Best serverless providers.
Web application architecture: Best practices for development
You can’t foresee all development problems lying ahead of you. But you can go for some popular approaches that might mitigate them.
Continuous integration (CI) and continuous delivery (CD) were created to divide web application development into independently managed and delivered components. Simply put, your engineering teams code, test, and integrate the app incrementally.
Companies can use CI/CD to improve integration testing and code stability. For example, you can implement a testable module that compiles and automatically tests code from different developers. Consequently, your team will know about errors and incompatibilities as soon as they happen.
The API-first methodology starts with planning and developing the mockup of an API. Then, after the stakeholders agree on the direction and interface requirements, the rest of the app can be developed in iterations as microservices.
API-first is the opposite of the code-first methodology, where engineers build the API around the code. As a result, the interface in the code-first projects may feel poorly optimized.
Blockchain is a peer-to-peer ledger of transactions where data is distributed across a network of computers.
The selected participant creates a new block of data, which contains a hash (a digital fingerprint) of the previous block and a set of transactions. Blockchain networks also use the proof of work mechanism that limits the number of data blocks that can appear at given intervals (for example, every ten minutes). To tamper with one block, you must modify proof of work and hashes for the subsequent blocks.
This creates a data chain that’s nearly impossible to alter undetected. Additionally, you can use a blockchain network to store parts of your data for additional security and resilience.
Containerization makes your web application portable. This technology is about packaging up the application along with related libraries, configuration files, and supporting dependencies into a single software package (container). The container is independent of the host operating system, allowing it to run on nearly any platform.
Containers make sense if you lack a clear plan on how to design web application architecture. You may also opt for containerization if you don’t want to tie yourself to a single environment.
Take AWS X-Ray as an example. It’s a distributed tracing system for microservice applications hosted on its platform. This tool can track, collect, and analyze data for every microservice and its underlying components. In turn, you’ll be able to identify root issues and bottlenecks even with a loosely coupled architecture.
The architecture of your software mirrors the applications you build. This interpretation of Conway’s law demonstrates the importance of web application architecture during development. So you better take your time to figure out the intricacies of the approach you’ll be selecting.
And if it’s not something you want to get too involved with, hire a software development vendor who knows web application architecture inside-out.
Acropolium is eager to help you out with our industry-specific knowledge and teams of vetted engineers, architects, and project managers. Together, we can transform your ideas into a feature-rich, secure, and high-performing app. Drop us a line to learn more.