In this article, I will check the limits of sending a request in a project. We will also have a general review of different layers to get more familiar with the nature of the request and response.

So let us first see what route a request from the user takes to reach our project:

When a user wants to view a website in a browser or register on a specific website, he must send a request to the server through his browser and wait for a response.

The request that the user sends determines how the server should respond; if the user wants to read or see information from the server, he should use the "GET" method, but if he wants to send information to the server, he should use the "POST" method. In most cases, these requests proceed from the user to the server on the "HTTP" protocol.

Imagine you have a site with many active users containing various functions. These functions can be storing and maintaining user information, buying a product, making a transaction, creating and receiving an Excel file on your site, and many other activities you may have seen so far.
Suppose we want to look at these users' activities from a developer's vision. In that case, we know that most of these events must be handled with the database. We also know that our code must be connected to the database, put specific data in it, and show it to the user.

So, I will divide my project into two parts for further review:

1- Logic of the project

2- Connecting to the database

The project's logic includes conditions, loops, arrays, etc., related to the developer's thinking. The performance may decrease due to the complexity of implementing a project. Alternatively, it may fail in a part of the project in general.

Connecting to the database and reading and writing to it is essential to our codes. Each connection to the database is an important weight on our project that we must be aware of and ensure that the number of these weights does not increase.

Meaning, that if we connect to the database through our project, it is better to close the connection when we are done.

Suppose we want to read a large number of records from the database. In that case, it is better to divide this information and read it with several different queries at different times. It is clear that if, for instance, we want to read a million records from the database with a query, we put a heavy overhead on the project, and most likely, the project will crash in the middle of the work.

Alternatively, if we want to insert one hundred thousand records into the database in one move with a loop, we will most likely encounter the status code 429, which indicates the "Too Many Request" error.

In this situation, it is better to use a queue. The queue performs the inserting process one by one, regularly and gradually. After inserting record number one, it goes to record number two.

Different languages and frameworks have provided methods for handling requests to prevent the application from crashing.

In the next chapter of this title, I want to check the limits of requests in the laravel project.