Introduction to three-tier architecture
Three-tier architecture is the most common interaction architecture on the Internet. It appeared when the two-tier server part was divided into two parts: a logic layer and a data layer .
It looked something like this:
The client layer is the part of the "distributed application" that is responsible for user interaction. This layer should not contain business logic and should not store critical data. Also, it should not interact with the database layer directly, but only through the business logic layer.
However, there is still some logic here. Firstly, this is interaction with the user through the interface, validation of the data entered by him, work with local files. This also includes everything related to user authorization and data encryption when working with the server.
Secondly, it is a simple business logic. For example, if an online store sent a list of products, we can sort and filter them on the client side. And primitive data storage is also here: caching, logged-in user cookies, and the like.
The business logic layer is located at the second level, most of the business logic is concentrated on it. Outside it, only fragments that are exported to the client, as well as logic elements that are immersed in the database (stored procedures and triggers) remain.
A very part of the business logic server contain not only this same logic, but also solve scaling problems: the code is divided into parts and distributed to different servers. Some highly demanded services can run on dozens of servers. The load between them is managed by the load balancer.
Server applications are usually designed in such a way that another copy of the server can be easily launched and started working in cooperation with other copies of it. That is, even in the process of writing server code, you will never have guarantees that your static class is launched in a single instance.
The data layer provides data storage and is placed on a separate level, implemented, as a rule, by means of database management systems (DBMS), connection to this component is provided only from the application server level.
Reasons for separating the data layer
The separation of the data layer into a full-fledged third layer occurred for many reasons, but the main one is the increased load on the server.
First, databases began to require a lot of memory and processor time for data processing. Therefore, they began to be placed everywhere on separate servers.
With increased load, the backend could easily be duplicated and ten copies of one server could be raised, but it was impossible to duplicate the database - the database still remained a single and indivisible component of the system.
Secondly, databases have become smart - they have their own business logic. They began to support stored procedures, triggers, their own languages such as PLSQL. And even programmers appeared who began to write code that runs inside the DBMS.
All logic that was not tied to data was taken out to the backend and launched in parallel on dozens of servers. Everything critically tied to data remained inside the DBMS, and there already the problems of the increased load had to be solved using our own methods:
- A database cluster is a group of database servers that store the same data and synchronize it using a specific protocol.
- Sharding - data is split into logical blocks and distributed across different database servers. It is very difficult to maintain database changes with this approach.
- The NoSQL approach is to store data in databases that are built to store huge amounts of data. These are often not even databases, but specific file storages. Very poor functionality compared to relational databases.
- Data caching. Instead of a simple cache at the database level, entire caching DBMS appeared, which stored the result only in memory.
It is clear that separate people and / or entire teams were needed to manage this zoo of server technologies, which led to the removal of the data layer into a separate layer.
Important! All advanced technologies are born in the depths of large IT corporations, when old approaches no longer cope with new challenges. Making databases into a separate layer was not invented by any programmer, but by a group of engineers somewhere in the depths of Oracle or IBM.
Interesting! When Zuckerberg started writing Facebook, he worked simply on PHP + MySQL. When there were millions of users, they wrote a special translator that translated all PHP code into C ++ and compiled it into native machine code.
Also, MySQL is not capable of storing the data of billions of users, so Facebook developed the concept of NoSQL databases and wrote a powerful server-side NoSQL DBMS - Cassandra. By the way, it is completely written in Java.
Application logic location ambiguity
And although a three-tier architecture almost unambiguously distributes roles between its parts, it is not always possible to correctly determine exactly where in the system a new part of the business logic (new code) needs to be added.
An example of such ambiguity is shown in the picture below:
The server part is filled with a gray background, the client part is filled with white. A good example of the latter approach (far right) is modern mobile apps. The client side (on the phone) contains the view (display), logic, and data. And only sometimes this data is synchronized with the server.
An example of the leftmost option is a typical PHP server, which has all the logic on the server, and it gives the client already static HTML. Somewhere between these two extremes, your project will be located.
At the beginning of work, after you get acquainted with the project, you will need to consult with the programmers working on it, about the places where it is better for you to implement the logic of the next task.
Feel free to do so. Firstly, they do not climb into someone else's monastery with their charter. Secondly, it will be easier for everyone (and you too) to find the code you need in the place where you expect to find it.