Learn from me the request of Laravel of Request life cycle

Overview

When using tools in the real world, if you understand how tools work, you will be more confident in using them. The same is true of application development. When you understand how development tools work, you will be more comfortable to use. The goal of this document is to provide a high-level overview of how the Laravel framework works. With a better understanding of the whole framework, the components and functions of the framework are no longer so mysterious, and it is easier to develop applications. This document contains a high-level overview of the request lifecycle, as well as startup files and application events.

If you can't understand all the terms immediately, don't lose heart. You can have a general grasp first, and continue to accumulate and digest knowledge in the process of reading other chapters of the document.

Life cycle of request

All requests sent to the application are processed via the public/index. php script. If you are using an Apache server, the. htaccess file included with Laravel will process all requests and pass them to index. php. This is the beginning of the Laravel process from accepting a client request to returning a response to the client. A general understanding of the boot process of Laravel (bootstrap process) will help to understand the framework, so we might as well discuss this first.

By far the most important concept required to learn the Laravel boot process is the service provider. Open the app/config/app. php configuration file, find the providers array, and you will find a list of service providers. These providers serve as the primary boot mechanism for Laravel. Before we dive into service providers, let's return to the discussion of index. php. When a request enters the index. php file, the bootstrap/start. php file is loaded. This file creates an Laravel Application object that also acts as the framework's IoC container.

After the Application object is created, the framework sets up some path information and runs environment detection. It then executes the boot script inside the Laravel source code and sets time zones, error reports, and other information based on your configuration file. In addition to configuring these trivial configuration options, the script does one very important thing: Register all the service providers configured for the application.

A simple service provider contains only one method: register. When an application object registers a service provider with its own register method, the service provider's register method is called. The service provider registers something with the IoC container through this method. Essentially, each service provider binds one or more closures into the container, and you can access the services bound to the application through these closures. For example, QueueServiceProvider registers multiple closures to use multiple classes related to queues. Of course, the service provider is not limited to registering content with the IoC container, but can be used for any boot-like task. Service providers can register event listeners, view synthesizers, Artisan commands, and so on.

After all service providers are registered, the files under app/start are loaded. Finally, the app/routes. php file is loaded. 1 Once the routes. php file is loaded, the Request object is sent to the application object and then dispatched to a route.

Let's sum up 1:

Request access to the public/index. php file.
The bootstrap/start. php file creates application objects and detects the environment.
The internal framework/start. php file configures the settings and loads the service provider.
Load the files in the app/start directory of the application.
Load the app/routes. php file for the application.
The Request object is sent to the application object, which returns 1 Response object.
Send the Response object back to the client.
You should have mastered how the Laravel application handles incoming requests. Let's look at the startup file.

Startup file

The startup file of the application is stored in the app/start directory. By default, this directory contains three files: global. php, local. php, and artisan. php files. For more information on artisan. php, refer to the documentation Artisan command line.

By default, the global. php startup file contains 1 basic items, such as log registration and loading the app/filters. php file. However, you can do anything you want in this file. It will be automatically included in _ every 1 _ request, regardless of the circumstances. The local. php file is executed only in the local environment. For more information about the environment, see the documentation configuration.

Of course, if you have other environments besides the local environment, you can also create startup files for these environments. These files will be automatically included when the application runs in this environment. Assuming you configure an development environment in the bootstrap/start. php file, you can create an app/start/development. php file that will be included in any request to the application in that environment.

What is stored in the startup file

Startup files are mainly used to store any "boot" code. For example, you can register the view synthesizer in the startup file, configure log information, or make some PHP settings. What to do is up to you. Of course, throwing all the boot code into the startup file will make the startup file cluttered. For large applications, or if the startup file is too cluttered, consider moving some boot code to the service provider.

Application event

You can also register before, after, finish, and shutdown application events to do a few things before or after processing request:

Register application events

App::before(function($request)

{

    //

});
App::after(function($request, $response)

{

    //

});

Listeners for these events run before (before) or after (after) each request that arrives at the application is processed. These events can be used to set the global filter (filter) or to modify the response (response) sent back to the client. You can register these events in a startup file or service provider.

The finish event is triggered when the response from the application is sent to the client. This event is suitable for handling the final finishing work required by the application. The shutdown event will be triggered immediately after all the listeners for the finish event are executed, which is the last chance if you want to do something more before the script ends. But in most cases, you don't need to use these events.