Welcome to the first lesson in your journey to designing a microservices architecture. Our goal is to build up the knowledge you need to design the architecture for a task manager web application.
To start, we won't jump directly into microservices. All distributed systems, including microservices, are built on the foundational principles of web applications. This first lesson focuses on the most fundamental concept: identifying the core components that make up almost every web application you use. By the end of this lesson, you'll be able to identify and explain the roles of the client, the server, and the database.
The Client-Server Model
At its heart, a web application operates on a client-server model. This is a foundational concept in distributed systems where one program (the client) requests services or resources from another program (the server).
To understand this model better, please read the following short text. It provides a clear, high-level overview of how clients and servers interact.
Understanding Web Application Architectures
This excerpt from 'Understanding Web Application Architectures' explains the fundamental client-server model used by most web applications.
Please read the section titled 'Client-Server'. Below the heading, read about the client-server model. Focus on understanding the distinct roles of the client and the server and how they communicate via HTTP requests.
As the text explains, the client is typically the user's web browser, and the server is a remote computer that hosts the application's code and data. When you visit a website, your browser (the client) sends a request to the website's server, which then sends back a response (the webpage content). This request-response cycle is the basis for all communication on the web.
The Three Core Components
While the client-server model describes the interaction, the application itself is typically composed of three distinct components:
- The Client (or Frontend): This is the part of the application that the user interacts with directly. It's responsible for presenting data and capturing user input. For a web application, this is what runs in your browser.
- The Server (or Backend): This is the engine of the application. It contains the business logic—the rules and processes that define what the application does. It receives requests from the client, processes them, and interacts with the database.
- The Database: This is the application's persistent storage. It's responsible for storing, retrieving, and managing all the data, such as user profiles, tasks, and project details.
Structuring the Components: The Three-Tier Architecture
A common and effective way to organize these components is through a three-tier architecture. This pattern separates the application into logical layers, or tiers, where each tier has a specific responsibility. This separation of concerns is a crucial principle in software architecture.
This simple diagram illustrates the concept clearly:
To get a more dynamic explanation of these tiers, let's watch a short video.
System Design: What is 3 tier architecture?
This video from the 'Be A Better Dev' channel provides a concise overview of the three-tier architecture and connects it to modern development stacks.
Please watch the architectural overview at the beginning of the video. Pay attention to how each of the three tiers—Client, Logic, and Data—is described and what its function is.
As the video explained:
- The Presentation Tier is the Client. It's the user interface (UI) rendered in a browser or a mobile app.
- The Logic Tier is the Server. This is where the core business logic lives. It processes requests, makes decisions, and serves as the intermediary between the client and the data.
- The Data Tier is the Database. It's solely responsible for data persistence and retrieval, ensuring data is stored safely and can be accessed efficiently.
An important rule in this architecture is that the tiers communicate in sequence. The client talks only to the server, and the server talks only to the database. The client never communicates directly with the database. This enforces a clean separation and enhances security.
Applying the Concepts to Our Task Manager
Let's make this concrete by applying it to our course project: the task manager application. How would these components map to its design?
An article on Medium sketches out a high-level design for a similar system. It's a perfect example of how these abstract components translate into specific technologies.
High-Level Design: Architecting the Task Management ...
This excerpt from 'High-Level Design: Architecting the Task Management ...' provides a practical example of the components of a task management application.
Please read the section titled 'Components Overview'. Below the heading, review the system components. Notice how the author maps the conceptual components to specific technologies (e.g., Frontend with Vue.js, Backend with Node.js).
As you can see from the article, for our task manager:
- The Client would be the Frontend—a web-based interface where users can view their task lists, click buttons to create new tasks, and mark tasks as complete.
- The Server would be the Backend. When a user creates a new task, the client sends this information to the server. The server would then validate the data (e.g., ensure the task has a name) and execute the logic to save it.
- The Database would be the system (like MySQL in the example) that permanently stores the information about users, tasks, projects, and their relationships.
Test your understanding!
Imagine you are designing the task manager. Match the application component (Client, Server, Database) to its primary responsibility.
Responsibilities:
- Persistently storing the title, description, and due date for every task.
- Executing the business rule that a new task cannot be assigned to a user who does not exist.
- Displaying a calendar view of all tasks due in the current month.
Show answer
- 1. Database: The database is responsible for all persistent storage of application data like task details.
- 2. Server: The server enforces business rules and logic. Validating data and relationships between entities (like tasks and users) is a core server function.
- 3. Client: The client is responsible for presenting data to the user in a human-readable format, such as a calendar view. It gets the raw data from the server and renders it.
Conclusion
In this lesson, we've established the foundational structure of a web application.
- Key Takeaways:
- Web applications are built on a client-server model, where a client requests information and a server provides it.
- The three core components are the Client (user interface), the Server (business logic), and the Database (data storage).
- The three-tier architecture is a common pattern that organizes these components into a Presentation Tier, an Application/Logic Tier, and a Data Tier, promoting a clean separation of concerns.
These three components are the fundamental building blocks we will be working with throughout this course. Whether we build a single large application or a system of small microservices, these core responsibilities—presentation, logic, and data storage—must always be accounted for.
Next Up: In our next lesson, we will bring these components to life by tracing the complete request-response cycle for a common operation, such as creating a new task. We'll follow the journey of data from the user's click in the browser all the way to the database and back again.