• Introduction
• When using any tool in "daily life", if you understand the working principle of the tool. Then it will be more convenient to use. The same is true for application development. When you can truly understand the implementation principle behind a function, it will be easier and more convenient to use it. The purpose of the documentation is to give you a clearer understanding of how the Laravel framework works. Get a holistic view through the framework so that everything no longer feels "magical." Trust me, this will help you become more aware of what you are doing and more confident about what you want to do. Even if you don’t understand all the terminology, don’t lose confidence! Just try it out a bit, learn how to use it, and your knowledge will surely grow as you move through other parts of the documentation.

First of all

All request entries for Laravel applications are public/index.php files. All requests are directed to this file via your web server (Apache/Nginx) through configuration. index.php The file doesn't have a lot of code, but it is the starting point for loading the rest of the framework. The

index.php file loads the Composer-generated autoload settings and then retrieves the instance of the Laravel application from the bootstrap/app.php script. The first action taken by Laravel itself is to create an application/service container.

HTTP/Console Kernel

Next, the incoming request is sent to the HTTP kernel or the Console kernel, depending on the type of request coming into the application. These two cores are used as central locations through which all requests pass. Now, let's take a look at the HTTP kernel located in app/Http/Kernel.php.

HTTP kernel inherits the Illuminate\Foundation\Http\Kernel class, which defines an array of bootstrappers. The classes in this array are run before the request is executed. These bootstrappers configure error handling, logging, checking the application environment, and other tasks that need to be performed before the request is processed.

The HTTP core also defines HTTP middleware that all requests must pass through before being processed by the application. These middleware handle HTTP session reading and writing, determine whether the application is in maintenance mode, verify CSRF tokens, etc.

HTTP core's handle method signature is quite simple: get a Request and return a Response. Think of this kernel as a big black box that represents the entire application, taking in HTTP requests and returning HTTP responses.

Service Provider

The most important thing in the kernel startup operation is the service provider you apply. The service providers under all applications are configured in the providers array in the config/app.php configuration file. In the first step, the register method of all service providers will be called, and then once all service providers are registered, the boot method will be called.

The service provider allows the framework to open a variety of components, such as databases, queues, validators, and routing components. As long as the service provider is started, it can control all functions of the framework, so the service provider is also the most important part of Laravel's entire boot cycle.

Request Scheduling

Once started and all service providers are registered, Request will be delivered to the router. The router will dispatch the request to the bound route or controller, and of course the route-bound middleware.

Focus on service providers

Service providers are the key to the true life cycle of Laravel. Once the application instance is created, the service provider is registered and then requested to be taken over by the launched application. Keep it simple!

It's extremely valuable to have a firm grasp of how service providers are constructed and how they work with Laravel applications. Of course, your application's default service providers will be stored under app/Providers.

By default, AppServiceProvider is blank. This provider is a good place to add your application's own bootstrap handling and service container bindings. Of course, in large projects, you may want to create several more fine-grained service providers.