An Introduction to Backend Architecture

Front-end seems to be one of the most popular developers’ niche over the last years. Front-enders create the front view of the web application. The code consists of HTML, CSS, and JavaScript. Three of them create the magic we all experience on the internet. But there is much more than a web application that needs to work. The back-end is the other side of the applications that we don’t see, but the experience. The back-end is the server’s code that gets the clients’ requests and sends the necessary data back. It also includes the application’s database that stores all the information. HTTP and REST guarantee the request-respond cycle’s structure between servers and clients.

Clients. What are those?

Anything that sends the request to the back-end can be considered a client. Basically, usual browsers send the request to the HTML and JavaScript which display the website. Note that there can be plenty of different clients like the mobile app, other service clients, and web-enabled smart appliances.

Back-end. What is it? 

Basically, the back-end receives the incoming request, interprets it, and sends the final response to the user. The back-end can be divided into three parts:

1. The computer receives a request.
2. The app that runs on the server and catches the request. Then it sends the response.

Server. What is it?

The server is a simple computer that catches the requests that are addressed to it. All computers can be connected to one network and behave like a simple server. If you are a developer, your computer is already a server. Note, that there are special computers that were made for receiving requests, but a regular computer will also work great. 

App’s main functions

Any application runs on the logic that dictates how to answer any request that is based on a simple HTTP verb and URI which stands for Uniform Resource Identifier. When HTTP and URI stand together, they are called a route. The matching request is called routing. Some functions are cross-platform software. Such code runs between the request-receiving service and a response-sending request. The functions of the cross-platform software will change an object that is requested, a query of the database, or process the request. As soon as such cross-platform software passes the control to the next function of the cross-platform software it ends and doesn’t send the response. When a function of a cross-platform software is called, then the request-respond cycle is ended. The client gets an HTTP response. The logic of routing can be simplified with the help of the Ruby framework or Express framework. Many coders use these frameworks during their work. One of many routes can have functions of a handler that run just when the HTTP and URI routes are matched!

The responses one server can send to a user

All data comes in many different forms when it hits the user. Just imagine you’ve sent a request and a server sends back an HTML file with JSON data. And your neighbor sent a request and got an HTTP status code. In any case, you’ve got the desired information. And you might be familiar with the «404. Not Found» page. That’s the answer to your request! However, there are many more mistakes that a server can send you back.

Consider using a database

Databases are crucial when it comes to the back-end of any web application. They provide a memory slot to save particular data. Such a concept alleviates the CPU memory’s load and gives the opportunity to restore data if the server dies or crashes at once. Also, a client might send data with the urge to appear on the database. 

Web API. What is it?

When software components need to communicate, they use API which is a methods’ collection for such communication. Also, there is a Web API which is the back-end created interface. Request types can be defined by Web API and it is defined by the routes. Such routes provide users with an expected answer. Web API provides a user with the data without being specific on how the data is displayed. Several HTML pages and mobile apps can be developed to check the Web API data. 

Some more request-response cycle basis:

• The server doesn’t create responses if there are no requests. 
  
• If there is a request, there should be a response as well, even if it is a 404 code. If there is no response – the user ends up waiting forever. 
  
• One response answer for one request. If there are more than one, you’ll run into errors. 

Map the request out!

Let’s imagine a real-life situation.

1. Alex tries to pick the shoes on shoesarehere.com. He clicks on a logo and sends a GET request. GET describes a specific kind of request. URI here describes a specific thing that Alex looks for (shoesarehere.com/products/12345)
   
2. Alex’s request surfs on the website through the categories on the server. There are lots of servers all around the world and the website request goes to the nearest server to provide the fastest speed. 
3. The closest server gets Alex’s request. 
   
4. There are event listeners that catch this request and respond to it. 
   
5. The response contains all the necessary information on the particular sneakers that Alex wants. It gives the data on this pair, including images.
   
6. The server receives the data.
   
7. This data surfs across the internet to reach Alex’s computer.
   
8. Alex sees all the information on his computer! 

And this is how the back-end works! Basically, a user sends a request via
servers and gets a response from the closest one!