Introduction
When using a tool in the “real world,” understanding how that tool works gives you more confidence in using it. The same is true of application development. When you understand how your development tools work, you can build applications more comfortably and confidently. This page provides a high-level overview of how the Laravel framework works. By understanding the framework as a whole, everything stops feeling like “magic,” and your confidence in building applications grows.HTTP request lifecycle
The overall flow
The first steps
The entry point for all requests to a Laravel application is thepublic/index.php file. All requests are forwarded to this file by your web server (Apache / Nginx) configuration. The index.php file itself contains very little code. It’s a starting point for loading the rest of the framework.
The index.php file loads the Composer generated autoloader definition and then retrieves an instance of the Laravel application from bootstrap/app.php. The first action Laravel takes is to create an instance of the application / service container.
HTTP kernel
Next, the incoming request is sent to the HTTP kernel (Illuminate\Foundation\Http\Kernel). The request is handled using the application instance’s handleRequest method.
The HTTP kernel defines an array of bootstrappers that run before the request is executed. These bootstrappers perform the following:
- Configure error handling
- Configure logging
- Detect the application environment
- Other tasks that need to happen before the request is handled
handle method is simple: it receives a Request and returns a Response. Think of the kernel as a big black box that represents your entire application. Feed it HTTP requests and it will return HTTP responses.
Service providers
One of the most important tasks during the kernel’s bootstrapping is loading your application’s service providers. Service providers are responsible for bootstrapping all of the framework’s various components, such as the database, queue, validation, and routing. Laravel iterates through the list of providers and instantiates each one. After instantiation, theregister method of every provider is called. Then, once all providers are registered, the boot method of each provider is called. This ensures that by the time a service provider’s boot method is invoked, all container bindings are registered and available.
User-defined and third-party service providers are registered in the
bootstrap/providers.php file.Routing
Once the application has been bootstrapped and all service providers have been registered, theRequest is handed off to the router for dispatching. The router dispatches the request to a route or controller, and also runs any route-specific middleware.
Middleware provide a convenient mechanism for filtering or examining HTTP requests entering your application. For example, Laravel includes middleware that checks whether the user is authenticated. If the user is not authenticated, the middleware redirects them to the login screen. If they are authenticated, the middleware allows the request to proceed further into the application.
Once the request has passed through all the middleware assigned to the matched route, the route or controller method is executed and a response is returned.
Returning the response
Once the route or controller method returns a response, the response travels back outward through the route’s middleware, giving the application a chance to modify or inspect the outgoing response. Finally, once the response has passed back through the middleware, the HTTP kernel’shandle method returns the response object to the application instance’s handleRequest method, which calls the returned response’s send method. The send method sends the response’s content to the user’s web browser. That completes the entire journey of a Laravel request lifecycle.
Console command lifecycle
The overall flow
The artisan entry point
The entry point for console commands is theartisan file in the project root. As with HTTP requests, the Composer autoloader is loaded and a Laravel application instance is created.
Next, processing is handed off to the console kernel via the application instance’s handleCommand method.
Console kernel and command execution
The console kernel also loads service providers, just like the HTTP kernel. After all providers have been registered and booted, the commands in theapp/Console/Commands directory are loaded and the specified command is executed.
- The
artisanfile loads the Composer autoloader - Creates the application instance from
bootstrap/app.php - The console kernel loads service providers
- Finds and executes the
make:controllercommand - Returns an exit code
Focus on service providers
Service providers are truly the key to bootstrapping a Laravel application. The application instance is created, the service providers are registered, and the request is handed to the bootstrapped application. That’s it. Having a solid grasp of how a Laravel application is built and bootstrapped via service providers is very valuable. Your application’s user-defined service providers are stored in theapp/Providers directory.
The default
AppServiceProvider is mostly empty. This provider is a great place to add your application’s own bootstrapping and service container bindings. For large applications, you may want to create multiple service providers, each with finer-grained bootstrapping for a specific service used by your application.The difference between register and boot
Service providers have two primary methods.| Method | Timing | Purpose |
|---|---|---|
register | Called for all providers after they’ve been instantiated | Only register bindings with the service container |
boot | Called after every provider’s register has completed | View composers, event listeners, and other initialization |
Next steps
Service container
Understand how dependency injection and the service container work.
Service providers
Learn how to bootstrap your application with service providers.