リクエストのライフサイクル
https://readouble.com/laravel/9.x/ja/lifecycle.html
公式ドキュメントにしたがって順番に読んでいきます。
最初はリクエストのライフサイクルです。
イントロダクション
このドキュメントの目的は、Laravelフレームワークがどのように機能するかについての概要を説明することです。フレームワーク全体をよりよく理解することで、すべてが「魔法」ではなくなり、アプリケーションの構築に自信が持てるようになります。
良いですね。以前も書いたように「習うより慣れよ」も大事ですがそれだといずれ行き詰まる気がするんですよね。
まずは俯瞰からフレームワークになにができるか、どんな構造なのか、どう機能するのかをまず概要レベルで知っておくことは大切だと思います。
最初のステップ
Laravelアプリケーションへのすべてのリクエストのエントリポイントは
public/index.phpファイルです。すべてのリクエストは、Webサーバ(Apache/Nginx)設定によってこのファイルに送信されます。ふむ、以前もXAMPPで「http://localhost/example-app/public/」に対してアクセスしましたね。
エントリポイントとはOSやプログラムが最初に実行する場所を指すようです。
OSだとMBRでしょうし、C言語だとmain関数ですね。
Laravelの場合は
public/index.phpがエントリポイントになるようです。index.phpファイルには多くのコードが含まれていません。むしろ、フレームワークの残りの部分をロードするための開始点と言えるでしょう。
index.phpファイルは、Composerで生成したオートローダー定義をロードし、Laravelアプリケーションのインスタンスをbootstrap/app.phpから取得します。Laravel自体が取る最初のアクションは、アプリケーション／サービスコンテナのインスタンスを作成することです。
index.php自体はさらに多段でここから各種処理を呼びだすようです。
確かに56行しかありません。
ざっと見ていきます。
8行目からメンテナンスモードに関する記述があります。
”/../storage/framework/maintenance.php”が存在するか確認していますね。
該当フォルダを探しましたが存在しませんでした。
メンテナンスモード
初めて聞きました、何でしょう？
この仕組みを使うと、運用中のシステムをメンテナンスする際に、一時的にユーザーをシステムにアクセスできないように制限することができます。
へえー、そんなことが出来るんですね。
じゃ実際にメンテナンスモードにしてみましょう。
まずは「http://localhost/example-app/public/」にアクセス
問題なく表示できます。
VSCodeでターミナルを開いて
php artisan downを実行します。
ブラウザで再度アクセスすると
503 Service Unavailable
確かにstorage/framework/maintenance.phpというファイルが生成されています。
maintenance.phpというファイルは79行ほどの短いファイルです。
同じフォルダの"down"というJSONファイルを読み込んで何かしてます。
php artisan upを実行します。
maintenance.phpとdownが削除されました。その後は普通に画面が表示されます。 
（追記）
コマンドはドキュメントルートで実行しないとダメらしいです。
違うフォルダで実行すると
”Could not open input file: artisan”
というエラーメッセージが表示されました。
maintenance.phpのパスが多分固定なんでしょうね。
自作のメンテナンスページを表示する
さっきは503 Service Unavailableという味もそっけもないメッセージでした。
独自画面を表示できるみたいですね。
resources/views/errors/
の下に画面を置けば良いようです。
errorsフォルダはないので作って以下を置きます。
php artisan downコマンドに-renderオプションを付けて作成した503.blade.phpを指定します。
php artisan down --render="errors::503"
ブラウザでアクセスすると想定した画面が表示されます。
メンテナンス中でも特定のユーザーはアクセスできるようにする
そんなことができるんですね。
php artisan upで元に戻してから
php artisan down --secret="naisyo"
でメインテナンスモードしてから
http://localhost/example-app/public/naisyo
でアクセスしてみます。
http://localhost/example-app/public
にリダイレクトされて通常画面が表示されました。
downというJSONファイルを見てみると
"secret"にさきほど設定した値が格納されています。
こうやって制御しているんですね。
ちょっと脱線しましたがソースコードに戻ります
index.phpファイルは、Composerで生成したオートローダー定義をロードし、Laravelアプリケーションのインスタンスをbootstrap/app.phpから取得します。Laravel自体が取る最初のアクションは、アプリケーション／サービスコンテナのインスタンスを作成することです。
 |
| index.htmlでのautoloader.phpの要求 |
/../vendor/autoload.phpを要求していますね。
オートローダを使うことで外部の機能を使うときにrequireを使ってファイルを指定する必要がなくなるそうです。
最後に”/../bootstrap/app.php”を要求しています。
 |
| index.htmlでのアプリケーションインスタンスの取得 |
Laravelのインスタンス作成
Laravelインスタンスの実態は以下ですね。
vendor/laravel/framework/src/illuminate/Foundation/Application.php
vendor/laravel/framework/src/illuminate/Foundation/Application.php
app.phpでのApplicationのインスタンス生成部分
Laravelインスタンスに対してHttpとConsoleのKernelをバインドしています。
最後に例外ハンドラをバインドしていますね。
 |
| app.phpでの重要なインターフェースのバインド |
HTTPカーネルのhandleメソッドの引数は非常に単純です。Requestを受け取り、Responseを返します。カーネルをアプリケーション全体を表す大きなブラックボックスであると考えてください。HTTPリクエストを取り込み、HTTPレスポンスを返します。
ふむふむKernelのhandleメソッドを見ると、受け取ったrequestに対してresponseを返していますね。
 |
| Illuminate\Foundation\Http\Kernel.phpのhandleメソッド |
サービスプロバイダ
最も重要なカーネル初期起動処理アクションの１つは、アプリケーションのサービスプロバイダをロードすることです。サービスプロバイダは、データベース、キュー、検証、ルーティングコンポーネントなど、フレームワークのさまざまなコンポーネントをすべて初期起動する責務を担っています。
Laravelが提供する基本的なすべての主機能は、サービスプロバイダによって初期起動および設定されます。フレームワークによって提供される非常に多くの機能を初期起動し設定するため、サービスプロバイダはLaravel初期起動プロセス全体の最も重要な側面です。
と書いてあります。
ざっとソース見たけどサービスプロバイダーをロードしてるところが分かりませんでした。
とりあえず「サービスプロバイダ」によってLaravelの主な機能が提供されているとメモして次へ進みます。
ルート
アプリケーションで最も重要なサービスプロバイダの１つは、App\Providers\RouteServiceProviderです。このサービスプロバイダは、アプリケーションのroutesディレクトリ内に含まれるルートファイルをロードします。どうぞRouteServiceProviderコードを開いて解析し、それがどのように機能するかを確認してください！とのことなので開いてみます。
が良く分かりません。これもスキップ
 |
| App\Providers\RouteServiceProvider.php |
アプリケーションが初期起動され、すべてのサービスプロバイダが登録されると、Requestがルータに渡されてディスパッチされます。ルータは、ルートまたはコントローラへリクエストをディスパッチし、ルート固有のミドルウェアを実行します。
以下のような状態遷移ってことですな。
クライアントからHTTPリクエストを送る
↓
アプリケーションが初期起動する
↓
サービスプロバイダを登録する
↓
HTTPリクエストをルータに渡す
↓
ルート固有のミドルウエアを実行する
ミドルウエアとは
ミドルウェアは、アプリケーションに入るHTTPリクエストをフィルタリングまたは検査するための便利なメカニズムを提供しています。たとえば、Laravelには、アプリケーションのユーザーが認証されているかを確認するミドルウェアが含まれています。ユーザーが認証されていない場合、このミドルウェアはユーザーをログイン画面にリダイレクトします。そしてユーザーが認証されている場合、ミドルウェアはリクエストをアプリケーションへ進めることを許可します。
アプリケーションに入る前にHTTPリクエストを色々処理できる機能のようですね。
例としてユーザ認証が挙げられていますね。
例えばURLを直打ちした場合でもアプリケーションに入る時点で認証がされているかどうかを確認して、もし認証がされていなければログイン画面へリダイレクトするような機能を実装することだと思います。
リクエストが一致したルートへ割り当てられたすべてのミドルウェアをパスした場合は、ルートまたはコントローラメソッドが実行され、ルートまたはコントローラメソッドが返すレスポンスがルートのミドルウェアチェーンを介して返送されます。
多分こんな感じの流れかな？
クライアントからHTTPリクエストを送る
↓
アプリケーションが初期起動する
↓
サービスプロバイダを登録する
↓
HTTPリクエストをルータに渡す
↓
ルート固有のミドルウエアを実行する
↓
ルートまたはコントローラメソッドを実行する
↓
ルートまたはコントローラメソッドの結果を返す
↓
ルート固有のミドルウエアの実行結果を返す
↓
クライアントがHTTPレスポンスを受け取る
サービスプロバイダに注目
サービスプロバイダは、Laravelアプリケーションを初期起動するための真の鍵です。アプリケーションインスタンスが作成され、サービスプロバイダが登録され、リクエストが初期起動を終えたアプリケーションに渡されます。とても簡単です！
Laravelアプリケーションがどのように構築され、サービスプロバイダを介して初期起動されるかをしっかりと把握することは非常に価値があります。アプリケーションのデフォルトのサービスプロバイダは、app/Providersディレクトリに保存されます。確かにAppServiceProvider.phpはスッカスカですね。
デフォルトのAppServiceProviderはほとんど空です。このプロバイダは、アプリケーション独自の初期起動処理およびサービスコンテナ結合を追加するのに最適な場所です。大規模なアプリケーションの場合、アプリケーションで使用する特定のサービスに対して、それぞれがよりきめ細かい初期処理を備えた複数のサービスプロバイダを作成することをお勧めします。
アプリケーション独自で機能を追加していくのでしょう。
 |
app/Providers/AppServiceProvider.php |
