リクエストライフサイクル
はじめに
現実世界でツールを使用する際、そのツールの仕組みを理解していれば、より自信を持つことができます。アプリケーション開発も同様です。開発ツールの機能を理解することで、より快適に、自信を持ってそれらを使用できるようになります。
このドキュメントの目的は、Laravelフレームワークの仕組みの概要を分かりやすく説明することです。フレームワーク全体をより深く理解することで、あらゆるものが「魔法」のように感じることが少なくなり、アプリケーションの構築に自信を持つことができるようになります。すべての用語をすぐに理解できなくても、落胆しないでください！基本的な把握を試みるだけで、他のドキュメントセクションを探求するにつれて、知識は深まります。
ライフサイクルの概要
最初のステップ
Laravelアプリケーションへのすべてのリクエストのエントリポイントは、`public/index.php`ファイルです。すべてのリクエストは、ウェブサーバー（Apache/Nginx）の設定によってこのファイルに送られます。`index.php`ファイルには多くのコードは含まれていません。むしろ、フレームワークの残りの部分をロードするための出発点です。
`index.php`ファイルはComposerによって生成されたオートローダー定義をロードし、次に`bootstrap/app.php`からLaravelアプリケーションのインスタンスを取得します。Laravel自体が最初に実行するアクションは、アプリケーション/ サービスコンテナ のインスタンスを作成することです。
HTTP/コンソールカーネル
次に、アプリケーションに入力されるリクエストの種類に応じて、アプリケーションインスタンスの`handleRequest`メソッドまたは`handleCommand`メソッドを使用して、着信リクエストがHTTPカーネルまたはコンソールカーネルのいずれかに送信されます。これらの2つのカーネルは、すべてのリクエストが流れる中心的な場所として機能します。ここでは、`Illuminate\Foundation\Http\Kernel`のインスタンスであるHTTPカーネルに焦点を当てましょう。
HTTPカーネルは、リクエストの実行前に実行される`bootstrappers`の配列を定義します。これらのbootstrappersは、エラー処理の設定、ログの設定、アプリケーション環境の検出、およびリクエストが実際に処理される前に実行する必要があるその他のタスクを行います。通常、これらのクラスは、心配する必要のない内部Laravel設定を処理します。
HTTPカーネルは、アプリケーションのミドルウェアスタックをリクエストに渡す役割も担っています。これらのミドルウェアは、HTTPセッション の読み書き、アプリケーションがメンテナンスモードかどうか、CSRFトークンの検証 などを処理します。これについては後で詳しく説明します。
HTTPカーネルの`handle`メソッドのメソッドシグネチャは非常にシンプルです。`Request`を受け取り、`Response`を返します。カーネルは、アプリケーション全体を表す大きなブラックボックスと考えてください。HTTPリクエストを入力すると、HTTPレスポンスが返されます。
サービスプロバイダー
最も重要なカーネルブートストラップアクションの1つは、アプリケーションのサービスプロバイダーをロードすることです。サービスプロバイダーは、データベース、キュー、バリデーション、ルーティングコンポーネントなど、フレームワークのさまざまなコンポーネントをブートストラップする役割を担っています。
Laravelは、このプロバイダーのリストを反復処理し、それぞれをインスタンス化します。プロバイダーをインスタンス化した後、すべてプロバイダーの`register`メソッドが呼び出されます。次に、すべてプロバイダーが登録されると、各プロバイダーの`boot`メソッドが呼び出されます。これは、サービスプロバイダーが、`boot`メソッドが実行されるまでに、すべてのコンテナバインディングが登録され、使用可能になっていることを前提としているためです。
基本的に、Laravelによって提供される主要な機能はすべて、サービスプロバイダーによってブートストラップされ、構成されます。フレームワークによって提供される非常に多くの機能をブートストラップして構成するため、サービスプロバイダーはLaravelのブートストラッププロセスの最も重要な側面です。
フレームワークは内部的に数十のサービスプロバイダーを使用していますが、独自のプロバイダーを作成することもできます。アプリケーションで使用されているユーザー定義またはサードパーティのサービスプロバイダーのリストは、`bootstrap/providers.php`ファイルにあります。
ルーティング
アプリケーションがブートストラップされ、すべてのサービスプロバイダーが登録されると、`Request`はディスパッチのためにルーターに渡されます。ルーターは、リクエストをルートまたはコントローラーにディスパッチし、ルート固有のミドルウェアも実行します。
ミドルウェアは、アプリケーションに入るHTTPリクエストをフィルタリングまたは検査するための便利なメカニズムを提供します。たとえば、Laravelには、アプリケーションのユーザーが認証されているかどうかを確認するミドルウェアが含まれています。ユーザーが認証されていない場合、ミドルウェアはユーザーをログイン画面にリダイレクトします。しかし、ユーザーが認証されている場合、ミドルウェアはリクエストがアプリケーションのさらに内部に進むことを許可します。`PreventRequestsDuringMaintenance`など、アプリケーション内のすべてのルートに割り当てられているミドルウェアもあれば、特定のルートまたはルートグループのみに割り当てられているミドルウェアもあります。ミドルウェアの詳細については、完全なミドルウェアドキュメントをご覧ください。
リクエストが一致するルートに割り当てられたすべてのミドルウェアを通過した場合、ルートまたはコントローラーのメソッドが実行され、ルートまたはコントローラーのメソッドによって返されたレスポンスがルートのミドルウェアチェーンに送り返されます。
仕上げ
ルートまたはコントローラーのメソッドがレスポンスを返すと、レスポンスはルートのミドルウェアを通って外側に移動し、アプリケーションは出力レスポンスを変更または検査する機会を得ます。
最後に、レスポンスがミドルウェアを通過すると、HTTPカーネルの`handle`メソッドはレスポンスオブジェクトをアプリケーションインスタンスの`handleRequest`に返し、このメソッドは返されたレスポンスで`send`メソッドを呼び出します。`send`メソッドは、レスポンスコンテンツをユーザーのウェブブラウザに送信します。これで、Laravelリクエストライフサイクル全体を巡る旅が完了しました！
サービスプロバイダーに焦点を当てる
サービスプロバイダーは、Laravelアプリケーションをブートストラップするための真の鍵です。アプリケーションインスタンスが作成され、サービスプロバイダーが登録され、リクエストがブートストラップされたアプリケーションに渡されます。本当にそれだけです！
サービスプロバイダーを介してLaravelアプリケーションがどのように構築され、ブートストラップされるかをしっかりと理解することは非常に価値があります。アプリケーションのユーザー定義サービスプロバイダーは、`app/Providers`ディレクトリに格納されています。
デフォルトでは、`AppServiceProvider`はほとんど空です。このプロバイダーは、アプリケーション独自のブートストラップとサービスコンテナバインディングを追加するのに最適な場所です。大規模なアプリケーションでは、アプリケーションで使用される特定のサービスのより詳細なブートストラップを行う、いくつかのサービスプロバイダーを作成することをお勧めします。