REQUEST LIFE CYCLE in the Laravel framework

INTRODUCTION

When you use a thing, you get much more pleasure from it when you understand how it works. Application development is no exception. When you understand exactly how your development tool functions, you can use it more confidently - not just copying the “magic” pieces to the manual or other applications, but knowing exactly what you want to get. The purpose of this document is to give you a good high-level look at how the Laravel framework works. In addition to this, we will look at start-up files and application events (application events).

Do not be discouraged if at first you will not understand any terms. Just try to get a basic understanding of what is happening, and your knowledge will grow as you study other parts of this manual.

REQUEST LIFE CYCLE

Using .htaccess Apache or Nginx rules or another web server, all requests are sent to the file public/index.php . From here Laravel begins the process of processing the request and here it returns the answer to the user.

Of course, the most important concept when studying the Laravel bootstrap process is the Service Provider (literally “service provider”, hereinafter “service provider”). You can find a list of service providers in the config/app.php file in the providers array. These providers are the main customization mechanism (bootstraping) of the Laravel functional. But before understanding their work in detail, let's go back to public/index.php . After calling it, the bootstrap/start.php file is bootstrap/start.php , in which the Application object is created, which also serves as the IoC container.

After creating the Application object, the paths to some important framework folders are set and the criteria for environment settings are set. Then, the framework setup script is invoked, which in addition to setting the timezone, error_reporting level, etc. does a very important thing - the registration of service providers, announced in config/app.php .

Simple service providers have only one method: register() . This method is called when the service provider registers with the Application object. In the frame of this method, service providers register some of their things with an IoC container. In essence, each service provider as a service provider adds one or more function closures to a container, which allows you to access these “services” in your application. For example, QueueServiceProvider registers the closure functions that resolve various classes associated with queues. Of course, service providers can be used for any actions to set up a framework, not only for registering things with an IoC container. The service provider can register event listeners, view composers, Artisan commands, etc.

After all service providers are registered, files are downloaded from app/start . Then app/routes.php , and based on which route is selected for work, the Request object is sent to Application .

Summarizing:

1. The request from the client comes to public/index.php .
2. bootstrap/start.php creates an Application object and defines the runtime environment.
3. The internal vendor/laravel/framework/src/Illuminate/Foundation/start.php reads and applies configs and registers service providers.
4. Files are loaded into app/start .
5. app/routes.php .
6. The Request object is sent to Application , the Response object is returned.
7. The Response object is sent to the client.

Now let's take a closer look at the files in app/start .

START FILES

The start files of your application are in the app/start folder. By default there are three of them: artisan.php , global.php and local.php .

You can find out about the artisan.php file in the Artisan section.

The global.php file, in particular, contains the Logger registration and the connection of the filter file app/filters.php . You can add to it what you want - this file is called at every request, regardless of the current runtime environment. The local.php file, as the name implies, connects only when the application is running in the local runtime environment. You can learn more about execution environments and their configuration in the corresponding section - Configuration.

If you have several other runtime environments in your application, such as production , you can create production.php . It will connect when the application is called in the appropriate environment.

What to place in the start-files

Start-up files are the place for the code that bootstrap your application. For example, you can register view composers there, set logging settings, set some PHP settings that your application needs. Of course, you should not put absolutely all initialization code in the start-files, as in this case it is easy to get confused in this code. If you understand that you have a garbage dump in the start files, allocate a part of the initialization code to the service providers.

EVENTS APPLICATIONS

Register event handlers

You can also pre-or post-process a request by registering event handlers before , after , close , finish and shutdown :

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

These handlers will be run, respectively, до and после each call in your application. These events are useful if you need to filter the request or modify the response globally for the entire application. You can register these handlers in the global start file or in one of your service providers.

You can also register an event that will be called by coincidence of the route (route). The event runs before the launch of the route.

 Route::matched(function($route, $request) { // }); 

The finish event is triggered after your application sends the generated response to the client. The shutdown event is triggered immediately after all the finish event handlers, and this is the last opportunity to do some actions before the application terminates. Most likely you will not need to use these events.

ANNEX 1. REQUEST LIFE CYCLE IN DETAILS

Standard life cycle:

The standard life cycle consists of the following items:

1. HTTP request through Routes (Routes) goes to the Controller (Controller)
2. The controller performs some actions depending on the request and transmits the data to the Views
3. Mappings display the received data in a specified way, providing an HTTP response.

There are many deviations and different variations of the above scheme, but it gives us three pivot points to pay attention to:

1. Routes - app/routes.php
2. Controllers - app/controllers/
3. Views - app/views/

"Deviations" can be, for example, such:

1. Routes can return Mappings or the Response itself (Response object) without using the Controllers.
2. Before or after the Routes, Filters can be triggered ( app/filters.php )
3. Exceptions or application errors may interfere with the process.
4. Responses to events.

Dig deeper

A deeper understanding of the life cycle of a query in Laravel will allow you to understand exactly where you can (and should) write your code.

The request cycle can be divided into three parts: Loading (Loading), Initializing (Booting) and Running (Running).

Loading (Loading)

Here are three main areas where your application can affect the framework loading process:

1. Workbench packages. Workbench is a way to organize your code into separate packages and test them inside your application before making them packages distributed through Composer. See Workbench

2. Runtime environment Depending on the installation environment, one or another configs, these or other start-files will be loaded.

3. Ways Editing bootstrap/paths.php you can change the framework file structure, placing the files in places convenient for you.

Initialization (Booting)

There are 10 areas where you can influence the framework initialization process.

1. Configs Configs affect both the initialization process and the framework operation process.

2. Service Providers Any service providers that you have created or connected to your application in the config config/app.php are loaded at the beginning of the initialization process. If the service provider is not set aside, its register() method is called.

3. Download and apply start files. Start-up files that need to be loaded are registered when the booted event is triggered.

4. A stack of middleware unfolds down Middleware nested into each other like nesting dolls. Upper middeware processes the request and calls the middleware of the next level, and so on. The last middleware calls the application. All middlewares are pushed onto the stack, and will be called again at the end of the Running part.

5. Initialization of service providers The boot() method is called on all registered non-deferred service providers.

6. Callbacks of pre-initialization All functions-closures registered in App::booting()

7. Post-initialization callbacks All closure functions registered in App::booted() called. The startup files registered in step 3 are loaded.

8. Global start files. First of all, it is app/start/global.php , then, if artisan-com *** is being executed, then app/start/artisan.php .

9. Startup file for the runtime. A file is executed that has the same file name as the name of the runtime environment, `app / start / {environment} .php

10. Routes Executed app/routes.php . You will edit this file most often during the development of your application.

Running

10 areas where you can influence the execution process:

1. Maintenance Mode If you have registered a subscriber function for maintenance mode and the application is in this mode, this function is performed.

2. Filter before application level If you have filters registered in App::before() , they are executed.

3. before filters in the routes. If you have before filters in routes, they are executed.

4. Execution of the request. After parsing which route the request belongs to, the action of the required controller or the callback of the route is called.

5. after filters in the routes. If you have filters after in routes, they are executed.

6. Filter after the application level If you have filters registered in App :: after (), they are executed.

7. The middleware stack is turning up. This is the point where the Response object is passed up through the stack of middlewares. Every middleware can change this object.

8. Middleware shutdown. If you have middlewares that implement TerminableInterface , the shutdown() method of these middlewares is called.

9. Callbacks finish If you have functions registered in App::finish() , they are executed.

10. Callbacks shutdown If you have functions registered in App::shutdown() , they are executed.