Request lifecycle of Laravel
We should understand Laravel’s Request lifecycle so that we may interact with/change request/response data or do anything else.
- Every server, including Apache, that makes a request redirect to the public/ index
- The index file loads the autoload function and creates an instance of the Laravel application.
- Because HTTP/kernels or console kernels receive all requests, we may refer to them as the primary location center for all requests.
- HTTP kernels specify a collection of bootstrappers that configure error handling, logging, app environment detection, and other features.
- HTTP kernels also specify a set of HTTP middleware for reading and writing the HTTP session, as well as validating the CSRF token.
- A response is produced by middleware’s handle method after receiving a request.
- Service Provider, which is situated in config/app, provides the database, queue, validation, routing components, and all other Laravel services.
- Laravel verifies them one by one and instantiates them, after which the register function of each provider is invoked.
- In order for service providers to rely on every container binding being registered and available by the time their boot method is executed, the boot method will be called once all providers have registered.
- If the application has previously been bootstrapped and registered with all of the services supplied by the service provider, the request will be sent to the router, which will route the request to a route, controller, or middleware.
- After returning from the route or controller, the response will be sent back to the route’s middleware, where we can modify it if necessary.
- The handle method of the HTTP kernel then returns the response, and the index.php file calls the send method on the returned response. The client or user will then see the response content on the browser that was sent via the send method.