Frontend & Backend

Well, we figured out the applications, we did the basic classification, we sorted out the types of web applications. But how does it work anyway?

And here we get to very important terms.

Frontend and Backend

The simplest illustration is theater. We come to the performance, we see the artists on the stage, we clap them, we get bows in return. And at the same time, we know for sure that the theater is not limited to the auditorium, and does not end with the stage. Somewhere costumes are sewn, preparations are underway in the dressing room, somewhere the director gives instructions. We do not see all that, but we know for sure that it is there, and without all that the theater would not be able to work.

In much the same way, everything is organized in web applications.

There is a layer that we see. The page that is displayed when we open some site. This page probably has some kind of animation and even buttons that you can click.

This visible layer is called “Frontend”. It includes everything that is on the user's side. Everything that is displayed on the screen of your device. Something that you can see and even feel.

But at the same time, we can be sure that everything is not limited to the frontend. After all, even the frontend itself, quite recently, is neither on the screen nor in the computer's memory. It appears when we decide to open another site and enter its address in the browser.

We make a request to display the site and receive a response. What blocks it has, where they are located, how they look, what fonts are used. We press a button and the command goes to the server to calculate some information, issue an answer, and provide a solution to the problem. This request and response system, Request-Response, is the cornerstone of how all Web applications work.

The request over the Internet goes to the server, to the side invisible to our eyes, to the “Backend”. At the same time, the request itself also contains certain information, it has some parameters. Based on this information, the backend decides which response to send (or it can nod politely, acknowledge receipt of the request, but do not transmit any more data).

HTTP

The data transfer protocol itself is called HTTP - HyperText Transfer Protocol. You can see these 4 letters at the beginning of the browser's address bar. This informs that the interaction will be carried out using the HTTP protocol. We can say that the parties agreed in what language they will communicate.

And don't let its name fool you. Indeed, at the dawn of the Internet, the protocol was conceived exclusively for hypertext. That is, text with links, with the ability to go to another page, get another text. Now it allows you to transfer any data: funny pictures, songs, dance videos from Tik-Tok.

In further modules of the course, we will deal with the structure of requests and responses in detail. We will create requests with responses, as well as the logic for their processing. At this stage, it is enough to understand the very principle of transferring data from the frontend to the backend and vice versa.

Databases

By the way, the data itself does not appear by magic. The appearance of requests on the frontend side is easy to understand - you enter them yourself. But in order to transfer information to you, you need to somehow organize its storage and processing.

For this purpose, “Databases” (DB) work. They store data in a structured form. And there are systems that manage this data - DBMS (Database Management System). They allow you to write new data to the database, get data from there, change it, delete it (All this together is denoted by the abbreviation CRUD - Create, Read, Update, Delete). We will also study all this in detail in future modules. Let's figure out what databases are in general, how their work is organized and how easy it is to manage them in AppMaster.io.