Understanding the architecture of a web application equips testers with the knowledge needed for comprehensive test planning. It enables them to identify critical components and cover various layers of the application. This understanding is essential for thorough test coverage. Plus, this is a welcome topic of discussion in job interviews.
What is architecture of web applications?
The architecture of web applications refers to the structural design and organization of components that make up a web-based software system. It encompasses the layout of these components, their relationships, and the principles governing their interactions. Think of it as the skeleton that gives structure to the application, allowing it to handle user requests and process data.
Web application architecture is typically organized into layers, each serving a specific purpose and responsible for specific aspects of the application's functionality.
Presentation layer. PL is responsible for presenting information to the user and capturing user interactions. It may involve rendering dynamic content on the client side using technologies like HTML, CSS, and JavaScript. User experience (UX) ensures a seamless and user-friendly interaction with the application.
Data service layer. DSL provides APIs or web services to facilitate communication between the presentation layer and the backend. It may handle data transformation and formatting before sending it to the presentation layer. Acts as an intermediary between the presentation layer and the backend, handling data exchange.
Business logic layer. BLL contains the core business logic and rules of the application. Manages the flow of data and processes within the application. Validates and enforces business rules on incoming data.
Data access layer. DAL interacts directly with the database to perform CRUD (Create, Read, Update, Delete) operations. Executes database queries and translates them into data structures usable by the business logic.
These layers collectively form a multi-tiered architecture, separating concerns and providing modularity and scalability to the application. Here's how they interact.
1. The presentation layer interacts with the data service layer:
PL communicates with the DSL to request and send data.
DSL provides APIs or web services that the PL consumes.
2. The data service layer interacts with the business logic layer:
DSL forwards requests from the PL to the BLL for processing.
It may transform and format data before passing it to the BLL.
3. The business logic layer interacts with the data access layer:
BLL communicates with the DAL to retrieve or persist data.
It applies business rules and logic to the data.
4. The data access layer interacts with the database:
DAL directly interacts with the database, executing queries and managing data storage.
This separation of concerns allows for easier maintenance, testing, and scalability. Changes in one layer can be made without significantly affecting others, promoting a modular and flexible architecture.
Components of web applications architecture
The components of web application architecture collectively contribute to the structure and functionality of a web-based software system. Each component plays a specific role, and their collaboration ensures the smooth operation of the application. Web application architecture includes 3 components.
It should be noted here that the architectures of the application and the website are different from each other. A website is usually a set of static pages that are designed to provide information. It may contain text, images, links, and other static elements. It does not necessarily require the presence of a database.
Web applications usually have a higher degree of dynamism. They can update without reloading the page, respond to user actions, and provide more sophisticated features. This most often requires a database.
1. Client side. This is the part of the application users interact with directly, what we see on the computer. Otherwise, this side is called the frontend. It involves:
User Interface (UI) – the visual elements that users interact with, including web pages, forms, buttons, and other graphical elements. It is typically built using HTML, CSS, and JavaScript.
Web browser – the client side application runs in a web browser, such as Chrome, Firefox, or Safari, which interprets and renders the UI elements.
2. Server side. This is where the application's logic resides. It processes requests from the client, interacts with databases, and performs other server side operations. Otherwise, this side is called the backend. Server side includes:
Application server – this handles the business logic of the application, processing requests from the client, interacting with databases, and executing server side operations. Technologies like Node.js, Django, Flask, Ruby on Rails, and Java Spring are commonly used for this purpose.
Web server – responsible for serving static files, handling incoming HTTP requests, and directing them to the appropriate application server. Popular web servers include Apache, Nginx, and Microsoft IIS.
3. A database is a data store where information is stored and retrieved. Databases can be relational or NoSQL databases.
Relational Database Management System (RDBMS) – stores structured data in tables with predefined relationships. Examples include MySQL, PostgreSQL, and Microsoft SQL Server.
NoSQL database – stores unstructured or semi-structured data and is suitable for handling large amounts of data with flexible schemas. Examples include MongoDB, Cassandra, and Redis.
To understand what to test, we need to understand what we are dealing with.
A user works with a client. It can be a web, desktop, or mobile application. That's why the tester first of all tests the client. The server can work perfectly, and even all the autotests can be successful. But the client may have an error. And the tester's task is to look from the user's point of view.
However, if you have access to the application server and its database, you should test them too! This way you can see the "future bug". For example, a user saves a product card - the system draws it and says that everything is fine on the client side. But after checking the database it turned out that some of the fields were empty, the developer incorrectly specified the name of the field in the database. And the information was lost.
What the user now sees in the client is just a cache, "what is entered is displayed". If you do not check the database, such a problem may not even reveal itself immediately. The user opens a product card, and there are some fields not filled in. If you have access to the database, the tester looks in the database to see if all the information is saved. If you have access to the server logs, you can check for errors there.
How do architectural elements interact with each other?
A frequent interview question: what is the difference between a two-tier architecture and a three-tier architecture? Here's the answer. The difference is a database. Simple applications do not always need a database, so in this architecture, there are only 2 sides: client and server. Hence the name, two-tier architecture.
The three-tier architecture (with data processing and storage logic) is used for applications that require a database. This architecture is the most popular, so let's consider it in more detail.
In a typical web application architecture, the interactions between the client, server, and database are orchestrated to enable seamless data flow and user interactions.
The client side begins with the user interacting with the UI elements, such as web pages, forms, and buttons, through a web browser. Users input data or trigger actions through the UI, such as submitting forms, clicking buttons, or interacting with dynamic elements.
When a user initiates an action, such as submitting a form or clicking a button, the client sends an HTTP request to the server. The request includes information about the action and any data associated with it. The web browser handles the HTTP request and awaits the server's response.
The application server receives the HTTP request. It processes the request, executes the necessary business logic, and may interact with the database to retrieve or manipulate data. The server then generates an HTTP response, which includes the data requested or the result of the operation. This response is sent back to the client.
The client, upon receiving the server response, renders the data or updates the UI accordingly which is displayed to the user, reflecting the changes initiated by their actions.
If the server side logic involves interacting with data, the server sends queries or commands to the database. The database processes the queries, retrieves or manipulates the requested data, and sends the results back to the application server. The application server incorporates the database results into the HTTP response sent back to the client.
Conclusion
We have covered the basics of building a web application architecture. In the next topics, we will talk about which architectures are used in modern applications and how to test them.