Step 1: Browser makes a request
The browser makes a request to the application. It is received by the applications index.php file. It captures this and creates a request instance.
Step 2: Application boots the kernel
The second step in the application is to boot its kernel.
For most cases, it has the default one in app/Http. But, if we are accessing the application through the console, Laravel has a specific kernel for that purpose.
Its main job is to configure ( not apply ) the middleware for all requests and some middleware for specific cases.
So, in general, the kernel simply boots up the application so that it can serve the request.
Step 3: Identify route and its server
In step 3, the application finds out what to do with the request. Or to be specific, who ( which controller ) will serve this request. Now, the application has a very flexible routing library embedded. Check out its document for more on this.
Now, we know who will be serving this request.
Route file should provide the explicit concept of the application.
Step 3: The middleware act – part 1
Now, we know who will be serving this request. But, should this be served at all?
The application has a group of middleware defined. Several built-in or you can handcraft some of them yourself. Pretty easy.
The request has to go through all of its global middleware and middleware assigned specifically for the request.
At the end, we get to know whether the request should be executed or not by the server.
- Is the user authenticated?
- Is the user making too much request at the same time?
- Is the user making this request with the valid approach (e.g. use of CSRF token)?
But, we can do more than that.
We can also manipulate the request data.
Laravel itself manipulates its request data. It trims the strings of the inputs and converts empty request variable to null.
Step 4: Request intervention
For example: if we are updating a post, Laravel has to decide the following:
- Should the user be allowed to carry out this specific request?
- Is this post created by the same user?
- Does this user have the right to update this post?
- Does the request contain enough data for the controller to return a valid response?
- Does it contain the title, post, and URL of the image?
- Are the data provided valid?
- Is the URL of image valid?
- Does the post id exist in the database?
- Is title too short or too long?
- What to do when the validation fails?
- What if URL is not valid?
- What message should we send back if not valid?
Step 5: Controller, Model, and Views
Assuming everything goes right up to this point, the controller does its job with the help of a model. It prepares some response – could be a VIEW or JSON or TEXT. It simply returns the response.
Step 6: The middleware act part 2
Since the response is prepared, now the request has to return the same way it came. i.e. through the middleware.
But, as similar to part 1, we can do something else here too. We can modify the response if required.
- Add some header information like content-length or timestamp on when the request was served.
- Log the request being complete.
After iterating through all these middleware, the server sends the response to the browser. Then, it sends the header information to close the connection.
But wait, it does not finish here. The application is not terminated yet.
Step 7: The middleware act: part 3 ( The Terminator )
Now, this step is optional. Imagine, you would like to perform additional activity even after the response has been sent to the browser.
Carrying out any operation here would not impact in any performance for the user. Because the server has already closed the connection with that user.
- We can bust the cache. For example, when a new row is added, the cached information is not valid anymore. So, we can clear it here.
- Notify administration about various activities. For example, a new user just signed up.
We can add a terminate method in the middleware.
Check this out for more elaboration.
BE CAREFUL WHAT YOU WISH FOR.
Step 8: End of the cycle
Now, we have come to the end of the request. The application simply halts.
Everything is awesome.