When using any tool in the "real world", you feel more confident if you understand how that tool works. Application development is no different. When you understand how your development tools function, you feel more comfortable and confident using them.
The goal of this document is to give you a good, high-level overview of how the Laravel framework works. By getting to know the overall framework better, everything feels less "magical" and you will be more confident building your applications. If you don't understand all of the terms right away, don't lose heart! Just try to get a basic grasp of what is going on, and your knowledge will grow as you explore other sections of the documentation.
The entry point for all requests to a Laravel application is the
public/index.php file. All requests are directed to this
file by your web server (Apache / Nginx) configuration. The
index.php file doesn't contain much code. Rather, it is a
starting point for loading the rest of the framework.
index.php file loads the Composer generated
autoloader definition, and then retrieves an instance of the Laravel
bootstrap/app.php. The first action taken
by Laravel itself is to create an instance of the application / service container.
HTTP / Console Kernels
Next, the incoming request is sent to either the HTTP kernel or the
console kernel, depending on the type of request that is entering the
application. These two kernels serve as the central location that all
requests flow through. For now, let's just focus on the HTTP kernel,
which is located in
The HTTP kernel extends the
Illuminate\Foundation\Http\Kernel class, which defines an
bootstrappers that will be run before the request
is executed. These bootstrappers configure error handling, configure
the application environment, and perform other tasks that need to be
done before the request is actually handled. Typically, these classes
handle internal Laravel configuration that you do not need to worry
The HTTP kernel also defines a list of HTTP middleware that all requests must pass through before being handled by the application. These middleware handle reading and writing the HTTP session, determining if the application is in maintenance mode, verifying the CSRF token, and more. We'll talk more about these soon.
The method signature for the HTTP kernel's
is quite simple: it receives a
Request and returns a
Response. Think of the kernel as being a big black box that
represents your entire application. Feed it HTTP requests and it will
return HTTP responses.
One of the most important kernel bootstrapping actions is loading the
service providers for your application.
Service providers are responsible for bootstrapping all of the
framework's various components, such as the database, queue, validation,
and routing components. All of the service providers for the application
are configured in the
config/app.php configuration file's
Laravel will iterate through this list of providers and instantiate
each of them. After instantiating the providers, the
register method will be called on all of the providers.
Then, once all of the providers have been registered, the
boot method will be called on each provider. This is so
service providers may depend on every container binding being registered
and available by the time their
boot method is
Essentially every major feature offered by Laravel is bootstrapped and configured by a service provider. Since they bootstrap and configure so many features offered by the framework, service providers are the most important aspect of the entire Laravel bootstrap process.
One of the most important service providers in your application is
App\Providers\RouteServiceProvider. This service
provider loads the route files contained within your application's
routes directory. Go ahead, crack open the
RouteServiceProvider code and take a look at how it
Once the application has been bootstrapped and all service providers
have been registered, the
Request will be handed off to the
router for dispatching. The router will dispatch the request to a route
or controller, as well as run any route specific middleware.
Middleware provide a convenient mechanism for filtering or examining
HTTP requests entering your application. For example, Laravel includes a
middleware that verifies if the user of your application is
authenticated. If the user is not authenticated, the middleware will
redirect the user to the login screen. However, if the user is
authenticated, the middleware will allow the request to proceed further
into the application. Some middleware are assigned to all routes within
the application, like those defined in the
property of your HTTP kernel, while some are only assigned to specific
routes or route groups. You can learn more about middleware by reading
the complete middleware documentation.
If the request passes through all of the matched route's assigned middleware, the route or controller method will be executed and the response returned by the route or controller method will be sent back through the route's chain of middleware.
Once the route or controller method returns a response, the response will travel back outward through the route's middleware, giving the application a chance to modify or examine the outgoing response.
Finally, once the response travels back through the middleware, the
handle method returns the response object and
index.php file calls the
send method on
the returned response. The
send method sends the response
content to the user's web browser. We've finished our journey through
the entire Laravel request lifecycle!
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. It's really that simple!
Having a firm grasp of how a Laravel application is built and
bootstrapped via service providers is very valuable. Your application's
default service providers are stored in the
By default, the
AppServiceProvider is fairly empty. This
provider is a great place to add your application's own bootstrapping
and service container bindings. For large applications, you may wish to
create several service providers, each with more granular bootstrapping
for specific services used by your application.