Init

output/12.x/lifecycle.md

@@ -0,0 +1,145 @@
+# Request Lifecycle
+
+  * Introduction
+  * Lifecycle Overview
+    * First Steps
+    * HTTP / Console Kernels
+    * Service Providers
+    * Routing
+    * Finishing Up
+  * Focus on Service Providers
+
+## Introduction
+
+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.
+
+## Lifecycle Overview
+
+### First Steps
+
+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.
+
+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 taken by Laravel itself is to create an
+instance of the application / [service container](/docs/12.x/container).
+
+### HTTP / Console Kernels
+
+Next, the incoming request is sent to either the HTTP kernel or the console
+kernel, using the `handleRequest` or `handleCommand` methods of the
+application instance, depending on the type of request entering the
+application. These two kernels serve as the central location through which all
+requests flow. For now, let's just focus on the HTTP kernel, which is an
+instance of `Illuminate\Foundation\Http\Kernel`.
+
+The HTTP kernel defines an array of `bootstrappers` that will be run before
+the request is executed. These bootstrappers configure error handling,
+configure logging, [detect the application
+environment](/docs/12.x/configuration#environment-configuration), 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 about.
+
+The HTTP kernel is also responsible for passing the request through the
+application's middleware stack. These middleware handle reading and writing
+the [HTTP session](/docs/12.x/session), determining if the application is in
+maintenance mode, [verifying the CSRF token](/docs/12.x/csrf), and more. We'll
+talk more about these soon.
+
+The method signature for the HTTP kernel's `handle` method 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.
+
+### Service Providers
+
+One of the most important kernel bootstrapping actions is loading the [service
+providers](/docs/12.x/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.
+
+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 executed.
+
+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.
+
+While the framework internally uses dozens of service providers, you also have
+the option to create your own. You can find a list of the user-defined or
+third-party service providers that your application is using in the
+`bootstrap/providers.php` file.
+
+### Routing
+
+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 `PreventRequestsDuringMaintenance`, while
+some are only assigned to specific routes or route groups. You can learn more
+about middleware by reading the complete [middleware
+documentation](/docs/12.x/middleware).
+
+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.
+
+### Finishing Up
+
+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 HTTP
+kernel's `handle` method returns the response object to the `handleRequest` of
+the application instance, and this method calls the `send` method on the
+returned response. The `send` method sends the response content to the user's
+web browser. We've now completed 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 user-defined service
+providers are stored in the `app/Providers` directory.
+
+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.
+