Role of web app architecture in development

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?

Architecture for web/mobile apps

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.

UI

The user interface (UI) is a visual presentation of a web app shown in a web browser and allows users to interact with it. It’s rare to find UI as part of the architecture, but it IS a component in modern apps since some of the business logic is done in the browser via JavaScript.

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).
  • JavaScript — programming language responsible for browser interactions.

The JavaScript layer rests in the user’s browser and communicates with the backend to update the webpage in real-time. In modern website architecture models, this allows the page content to change dynamically as users interact with the interface elements.

Web server

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 server

Database servers are centralized locations for databases (organized collections of information). These servers communicate with web servers and provide data to authorized users.

Elements of a modern web application

DNS

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 (8.8.8.8).

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.

Messaging middleware

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.

Load balancer

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.

Cache

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).

CDN

The content delivery network (CDN) is a system of server nodes that store and deliver static content (images, audio, videos, CSS, and JavaScript files). CDNs can improve the latency for users who live far away from data centers where your web app is hosted.

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.

Read also: How to find a Software architect for your startup.

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.

  1. The client (browser) contacts a DNS server, which provides the IP address.
  2. The browser then sends a request for web documents (JSON, HTML, and others) to the web server.
  3. 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.
  4. If the request meets the access criteria, the app logic loads data from the database and sends them to the browser.
  5. The browser receives a web document with data, parses it, and loads any static files (JavaScript, CSS, images, video, etc.) from the CDN.
  6. In modern web applications, the app logic may have the JavaScript layer, which then communicates with the backend and different APIs from the browser.
  7. 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

Three 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.

Presentation layer

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.

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.

Persistence layer

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:

  1. The user interacts with the presentation layer via a browser.
  2. The presentation layer sends requests to the business logic tier.
  3. The latter evaluates these requests and communicates with the persistence tier to retrieve the necessary data.
  4. The business layer routes the data to the presentation layer.
  5. 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

Different types of architectures for web apps

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.

Frontend

Traditional SSR vs dynamic SPA web application architecture

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.

Single-page application

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:

  1. The web server generates a single web page with minimal HTML data and a JavaScript layer.
  2. The JavaScript layer communicates with the backend to fetch the data and render the remaining HTML. It also provides real-time updates.

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

Progressive web app architecture as a hybrid between web and mobile

Progressive web application (PWA) architecture is a hybrid of SPAs and mobile apps. In addition to dynamic JavaScript code, PWAs use:

  • 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.

Backend

Microservices

Microservices framework for web development

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

Serverless architecture is a cloud infrastructure hosted by third-party providers, such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud.

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

Practices and tech for web app design & development

You can’t foresee all development problems lying ahead of you. But you can go for some popular approaches that might mitigate them.

CI/CD

CI/CD pipeline for development in microservice web app architecture

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.

API-first

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.

JAMstack

JAMstack is a dynamic pre-rendering approach based on JavaScript, pre-built hypertext markup, reusable APIs, and CDNs. Here’s how it works.

Your web app is fully rendered in advance and resides on the CDN. Upon user request, the web app is delivered from the CDN to the user’s browser in a timely manner. With JavaScript in a browser, the app can extend its functionality using third-party APIs.

Blockchain

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

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.

Monitoring

Observability is quite troublesome in loosely coupled environments (microservices). You can’t implement an application monitoring tool using only JavaScript to monitor the entire app. But there are turnarounds.

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.

Read also: How to improve time to market: Acropolium’s approach.

Conclusion

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.