Software architecture refers the structure created within an application, i.e. the entire program's modules and components and how they interact.
Programmers have been working on good architectures for a very long time, so it is not surprising that we've heard of a lot of architectural patterns. You need to understand them: when writing a web application, it is critical to come up with a good architecture, because a web application has more components and modules than a regular application.
An architectural pattern is a smart way to solve some software design problem.
You've probably come across design patterns such as factory method, abstract factory, builder, prototype, singleton, and possibly others. We use them to when writing code, creating classes, and planning how classes will interact.
Architectural patterns are used at a higher level of abstraction, when planning the user's interaction with servers, data, and other components. Let's take a quick look at some patterns and how to use them.
Client-server architecture
The name creates the impression that everything about this pattern is simple and clear. But let's clarify some points, so that when you begin to study Spring you will understand what we're talking about. Let's say you've written a chat app, and you and a friend start using it. You could adopt a very simple approach, sending messages to each other directly via the Internet using known IP addresses:
At first, everything seemingly works fine until another one of your friends asks to join the chat.
So when you decide to add your mutual friend to the chat, you face an architectural problem: for each chat participant, you need to provide current information about the number of users, and the IP address of new users. And when a message is sent, it needs to be delivered to all participants. These are the most obvious problems that will arise. Another bunch of problems will be hidden in the code itself.
To avoid them, you need to use a server, which will store all the information about users, including their addresses. Messages only need to be sent to the server. It, in turn, sends messages to each of the recipients. When you decide to add a server part to your chat app, you are beginning to build a client-server architecture.
Components of the client-server architecture
Let's see what it's all about. A client-server architecture is a design pattern used to create web applications. This architecture consists of three components:
Client — From its name, we can tell that this component uses some service (the web application), contacting a server to request some information.
Server — This is where your web application or the server part of it is located. It stores the necessary user information or can request it. Additionally, when a client sends a request, it is the server that returns the requested information.
Network — This part is simple. It facilitates the exchange of information between the client and server.
a client module — contains a graphical interface for signing in and sending/receiving messages
a server module — a web application that is hosted on a server and receives messages from users, processes them, and then sends them to recipients
When we want to look at useful (or not very useful) information on the Internet, we open a browser, enter a query in the search bar, and get information from the search engine in response.
In this chain, the browser is the client. It sends a request with information about what we are looking for to the server. The server processes the request, finds the most relevant results, packages them in a format the browser (client) can understand and sends them back.
Complex services like search engines can have a lot of servers. For example, an authorization server, a server for finding information, a server for generating the response, etc. But the client is unaware of and unconcerned about any of this: for the client, the server is a unified entity. The client only knows about the entry point, that is, the address of the server to which requests should be sent.
Recall the application that we examined in the previous part of this series. It was for monitoring the average air temperature in all countries in real time. Its architecture looks something like this:
Our application is located on the server. Let's say that every five seconds it sends requests to servers operated by local meteorological stations, receives temperature information for a particular country from the servers, and stores this information. When the client asks us to "view the world's current air temperature", we return the most recently stored information, sorted by country.
Thus, our application acts as both a server (when it processes user requests) and a client (when it receives information from other servers).
| Here's an important point: the concept of a server is not about a specific computer, but rather about the relationship between network entities. |
Three-tier architecture
This is an architectural pattern that introduces a third module — data storage. In this pattern, the three levels are usually called layers or tiers:
The client layer is the user interface, also called the presentation tier. It can be a web browser that receives HTML pages, or a graphical user interface written using JavaFX. The main thing is that this layer lets the user send requests to the server and process its responses.
The logic layer is the server that processes requests/responses. Often it is also called the server layer. This is also where all logical operations take place: mathematical calculations, data operations, calls to other services or data storages, etc.
The data layer is the database server: our server interacts with it. This layer stores all the information necessary for the application to operate.
Advantages of a three-tier architecture
An architecture like this gives us many advantages, including:
The ability to protect against SQL injection (this is an attack on a server; it involves sending SQL code that, when executed, allows an attacker to affect our database).
Separation of the data to which we want to control user access.
The ability to modify data before sending it to the client.
Scalability (the ability to expand our application to multiple servers that will use the same database.
Lesser stringent requirements on the quality of user connections. When generating a response on the server, we often get a lot of different information from a database and format it, leaving only what the user needs. Doing this reduces the amount of information that we send in our response to the client.