Laravelが文字列Hello Worldを画面に表示するまでの仕組みを理解する
2023.08.07
概要
Laravelに入門するために、リクエストを受け取ってからレスポンスを返すまでの仕組みをたどってみます。
ゴール
Hello Worldを題材にソースコードをざっくり読んでみることで、Laravelがどのようにリクエストをもとにレスポンスを組み立てているのか、概要を掴むことを目指します。
つまり、Laravelがどうやって動いているのか、ぼんやりとでもイメージできるようになることが目標です。
環境
- PHP8.1
- Laravel10.0
目次
- 概要
- ゴール
- 環境
- 目次
- 用語
- 背景
- ざっくり要約
- 方針
- 全体像を知る
- ソースコード探検
- エントリーポイント(public/index.php)
- Service Containerの生成(app.php)
- Service Containerの仕組み
- Container::singleton()-オブジェクトのつくり方を登録
- Container::bind()
- Container::make()
- Container::resolve()
- オブジェクトのつくり方を読み出す-Container::getConcrete()
- オブジェクトをつくる-Container::build()
- 補足: Closureが呼ばれてから元の処理に合流するまで何が起こっているのか
- 補足: なぜこのような周りくどい仕組みが存在しているのか
- 今度こそオブジェクトをつくる-Container::build()
- 戻り値を返すまで-Container::resolve()
- Service Containerの概要ざっくりまとめ
- Service Containerのコンストラクタ
- Service Provider
- 復習-Laravelが動く前準備が整うまで
- Request::capture()
- Kernel::handle
- Kernel::sendRequestThroughRouter()
- Kernel::dispatchToRouter
- Route
- Router::findRoute()
- Router::runRoute()
- 振り返り
- まとめ
用語
※ 用語の詳細は記事で掘り下げていきます。
- リクエスト/レスポンス: HTTPリクエスト/HTTPレスポンスを指す
- オブジェクト: クラスのインスタンスと同義
- Service Container: いわゆるDIコンテナ Laravelではオブジェクトの作成・提供を責務に持つ
- Service Provider: どういうオブジェクトをどうやってつくるのか機能単位にまとめたもの
- Kernel: 核心などを意味する Laravelにおいてはアプリケーションを制御することを責務に持つ
- Bootstrapper: 設定ファイルを読み出すなど、Laravelが動作するのに必要な準備を表す処理をまとめたもの
背景
Webアプリケーションフレームワークを理解する上で、リクエストからレスポンスを組み立てるまでの流れを知ることはとても重要です。
公式でも書かれている通り、仕組みを理解すれば自信をもってLaravelを利用したコードが書けるようになるはずです。
仕組みを知り、自信をもつということは言い換えれば不具合や課題など、さまざまな種類の問題を解決する力を手にいれることを意味します。
Laravelともっと仲良くなるためにも、リクエストを扱う一連の流れを探っていきましょう。
ざっくり要約
public/index.phpが入り口。Laravelの核となるKernelが個々の処理を制御する。
まず、Laravelが動作するのに必要なオブジェクトをService Containerを介して生成。
具体的にどのオブジェクトをつくるのかは、Service Providerによって規定されている。
そして、リクエストを処理するのに必要なオブジェクトがそろったら、KernelオブジェクトがRouteオブジェクトを介して対応する処理を呼び出す。
出来上がったレスポンスを返却することで、処理が完了。
方針
Laravelがリクエストを処理するまでの道のりは、膨大な量のコードで構成されています。
すべてを読んでいると迷子になってしまうので、最初にやりたいことを決めておきます。
今回は見る範囲が広いので、2回に分けて全体の処理をたどっていきます。
具体的には、最初にLaravelがレスポンスを生成するために何をしているのか概要を見ていきます。先に全体像を押さえておくことで、詳細を見るときに何を目的とした処理なのか掴めるようになることを目指します。
続いて、具体的な仕組みを解き明かします。細部に入り込みすぎない程度に眺めていき、ざっくりどうやって実現しているのか主要なところを押さえていきます。
全体像・仕組みを押さえることができれば、Laravelがどうやって動いているのか多少なりとも見えてくるはずです。
範囲
Laravelのアプリケーションでは、データベースやBlade Templateなどを組み合わせることで、複雑な画面や機能も実装することができます。
とはいえ入門段階でこれらも含めた仕組みを解き明かそうと思うと、範囲が広すぎて途中で折れてしまいそうです。
よって、今回はいわゆるHello Worldに相当する処理がどのように実行されるのか、理解するところを目標とします。
より具体的には以下のような、レスポンスとして文字列を返却するようなコードを見ていきます。
1 2 3 4 5 | // routes/web.php Route::get('/hello', function (Request $request) { // Hello Laravel from hello return "Hello Laravel from {$request->path()}"; }); |
それでは最初に全体像を知るために、リクエストからレスポンスをつくりだすときにLaravelが何をしているのか、簡単に見ていきます。
全体像を知る
文字列をレスポンスとして返すだけでも、Laravelではたくさんの処理を見ていくことになります。
ですので、いきなりコードから探り始めると、今見ている処理が何を目的としたものなのか見えてこず、理解が曖昧になってしまうかもしれません。
そこでまずは、Laravelがリクエストを扱うときに重要なオブジェクトの名前と役割をざっくり見ておきます。
どんな責務を持った処理が何をしているのか明らかにできれば、全体像も掴めてくるはずです。
必要な責務
細かな役割を見ていく前に、「リクエストからレスポンスを組み立てる」ためにどういう処理が必要か整理しておきましょう。
処理とは具体的に何か掘り下げておくことで、これから見ていくオブジェクトが処理のどの部分を担ってくれるのかイメージできるようにします。
具体的な流れは、以下の通りです。
- リクエストをWebサーバから受け取る
- リクエストを扱うのに必要なオブジェクトを用意
- リクエスト先のURLをもとに呼び出す処理を振り分け
- 該当する処理を呼び出し、リクエストをもとにレスポンスを生成
- 出来上がったレスポンスをWebサーバへ返却
Webアプリケーションフレームワークを触ったことがあれば、なんとなくイメージできるかと思います。
Laravelがこのような処理をどうやって実現しているのか、関係する主なオブジェクトを見てみます。
Service Container-オブジェクトを用意して提供
Laravelを構成するオブジェクトを用意・提供する処理は、Service Containerなるオブジェクトが担います。
これはいわゆるDIコンテナと呼ばれるものです。DIコンテナの役割やメリットはテストコードを題材とした方がわかりやすそうですが、今回は実装までを追うのが目標なので、割愛します。
先に概要を把握しておきたい方は、参考リンクの記事を読んでみてください。
実装の観点から見るService Containerの大きな役目は、リクエストを処理していくのに必要なオブジェクトを用意・提供することです。
これだけではイメージしづらいので、最初に見たHello Worldのコードを見てみましょう。
1 2 3 4 5 | // routes/web.php Route::get('/hello', function (Request $request) { // Hello Laravel from hello return "Hello Laravel from {$request->path()}"; }); |
重要なのは、メソッドの引数で渡しているClosureです。この処理はHTTPリクエストを表わすRequestオブジェクトを受け取っています。
このように欲しいクラスを書いておくだけでインスタンスが得られるのは、Service Containerの恩恵によるものです。
※ ControllerのメソッドでRequestオブジェクトを受け取る場合も同様に考えられます。
少し話が抽象的になってきたので、ひとまずはService Containerがあることで、Laravelアプリケーションではオブジェクトを用意するのが楽になるんだな、ということを覚えておきましょう。
Service Provider-Laravelが動き出すための指示書
Service Containerのおかげでオブジェクトを用意できる仕組みは整っているようです。
しかし、簡単にオブジェクトが用意できるようになっても、Laravelで扱うオブジェクトの数は膨大です。これを1つ1つ設定して準備するのは大変そうです。
そこで、Laravelではセッション管理やデータベースなど、機能を実現するためのオブジェクトをどうやって組み立てるのか表現したクラスが用意されています。
これは、機能(Service)を提供するための役割を持つことから、Service Providerと呼ばれます。
具体例として、コードが比較的シンプルなHashServiceProviderクラスを見てみましょう。このクラスは、パスワードのハッシュ化など、ハッシュ化処理に関係する機能を用意するのが役割です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | namespace Illuminate\Hashing; use Illuminate\Contracts\Support\DeferrableProvider; use Illuminate\Support\ServiceProvider; class HashServiceProvider extends ServiceProvider implements DeferrableProvider { // register()にて、機能を実現するのに必要なオブジェクトを設定 /** * Register the service provider. * * @return void */ public function register() { // Service Containerに指示 // hashという名前のオブジェクトが要求されたら、HashManagerオブジェクトをつくって渡す $this->app->singleton('hash', function ($app) { return new HashManager($app); }); $this->app->singleton('hash.driver', function ($app) { return $app['hash']->driver(); }); } // 中略... } |
HashServiceProvider::register()の役目は、機能を実現するのに必要なオブジェクトを用意しておくことです。
オブジェクトをつくるとなるとスコープが気になるところですが、Service Containerがよしなに管理してくれます。
Service Containerが管理してくれていることで、必要に応じて必要な場所でオブジェクトを取り出せるようになります。
まとめると、Service Providerの責務はService Containerを介し、Laravelの各種機能を実現するためのオブジェクトを用意することです。
Service Containerと同様、普段の実装ではあまり意識することはありませんが、Laravelを支えるとても重要なオブジェクトです。
Kernel-Laravelの核
Kernelは、Laravelのドキュメントではあまり触れられていない機能です。
ですが、Kernelという英単語が物事の核心といった意味を持つように、LaravelにおけるKernelクラスはとても重要な役割を担っています。
Kernelの責務は、Laravelアプリケーションを動かすことです。
より具体的には、これまで紹介してきたService ContainerやService Provider・そして私達が実装するアプリケーションと協力し、HTTPレスポンスなどの出力をつくりだします。
どのように協力していくのかは、ソースコードを見るときにじっくり探っていきます。
よってここでは、KernelはLaravelアプリケーションを制御する司令塔のような役目を果たしているんだな、ということを押さえておきましょう。
全体像の振り返り
ざっくりとではありますが、Laravelがリクエストを捌く上で重要な要素を見てきました。忘れないよう、簡単に復習しておきましょう。
- Laravelの機能を表現するオブジェクトを生成して取り出す処理は、Service Containerが担当
- Service Containerを利用し、どんなオブジェクトをつくっていくかはService Providerが管理
- Kernelが司令塔となってそれぞれの処理を呼び出し、リクエストからレスポンスをつくっていく
Laravelが何をしているのかは、ぼんやりと見えてきました。
よってここからは、具体的にどうやってリクエストを処理しているのか、Laravelの仕組みを覗いてみます。
ソースコード探検
Laravelのソースコードを探検しながら、仕組みを解き明かしていきます。すべてを読むと迷子になってしまうので、雰囲気を掴める程度に見てみましょう。
エントリーポイント(public/index.php)
最初の一歩として、リクエストを扱う処理の入り口である public/index.phpから始めます。
nginxなどのWebサーバを利用していれば、このファイルがエントリーポイントであるのもなんとなくイメージできるかと思います。
一方、開発するときによく実行する php artisan serveコマンドとは結びついていないように見えます。このコマンドの仕組みもこの場で解明したいところですが、入り込むと少し長くなってしまうので、補足に譲ることにします。興味があったら見てみてください。
それではソースの中身を覗いてみましょう。
Auto Loader
最初に、Laravelアプリケーションに登場するPHPクラスファイルを読み込めるよう、Auto Loaderを読み出しておきます。
1 2 3 4 5 6 7 8 9 10 11 12 | // public/index.php /* |----------------------------------------------------------------------- | Register The Auto Loader |----------------------------------------------------------------------- | | Composer provides a convenient, automatically generated class loader for | this application. We just need to utilize it! We'll simply require it | into the script here so we don't need to manually load our classes. | */ require __DIR__.'/../vendor/autoload.php'; |
Applicationクラス
続いて、 bootstrap/app.phpファイルを読み出しています。
1 2 3 4 5 6 7 8 9 10 11 | /* |----------------------------------------------------------------------- | Run The Application |----------------------------------------------------------------------- | | Once we have the application, we can handle the incoming request using | the application's HTTP kernel. Then, we will send the response back | to this client's browser, allowing them to enjoy our application. | */ $app = require_once __DIR__.'/../bootstrap/app.php'; |
以降ではapp.phpへ制御が移ります。
Service Containerの生成(app.php)
app.phpで最も重要な処理は、以下のコードです。
1 2 3 4 5 6 7 8 9 10 11 12 13 | // bootstrap/app.php /* |----------------------------------------------------------------------- | Create The Application |----------------------------------------------------------------------- | | The first thing we will do is create a new Laravel application instance | which serves as the "glue" for all the components of Laravel, and is | the IoC container for the system binding all of the various parts. | */ $app = new Illuminate\Foundation\Application( $_ENV['APP_BASE_PATH'] ?? dirname(__DIR__) ); |
Applicationなるオブジェクトをつくっています。これは、Service Containerを表しています。
Service Containerの理解を深めるためにも、ざっくりと何をしているのか探ってみましょう。
Applicationクラス(Service Container)
まずは呼び出されていたコンストラクタを確認してみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | // Illuminate/Foundation/Application.php class Application extends Container implements ApplicationContract, CachesConfiguration, CachesRoutes, HttpKernelInterface { use Macroable; // 中略... /** * Create a new Illuminate application instance. * * @param string|null $basePath * @return void */ public function __construct($basePath = null) { // 中略... $this->registerBaseBindings(); $this->registerBaseServiceProviders(); $this->registerCoreContainerAliases(); } // 中略... } |
色々重要そうな処理はありますが、いきなり細部に入り込むのはやめておきます。
ここで書かれた処理をイメージできるようになるには、Service Containerの大まかな仕組みを理解しておかなければなりません。
そうなると、Service Containerの理解を深めるために何から手をつければ良いか迷ってしまいそうです。しかし実は、後続のコードにService Containerの仕組みを読み解くのにうってつけなものが書かれています。
少し先を見ておきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | // bootstrap/app.php // これまで見てきたService Container生成処理 $app = new Illuminate\Foundation\Application( $_ENV['APP_BASE_PATH'] ?? dirname(__DIR__) ); // 中略... // Service Containerを呼び出しているっぽい処理 $app->singleton( Illuminate\Contracts\Http\Kernel::class, App\Http\Kernel::class ); // 中略... /* |----------------------------------------------------------------------- | Return The Application |----------------------------------------------------------------------- | | This script returns the application instance. The instance is given to | the calling script so we can separate the building of the instances | from the actual running of the application and sending responses. | */ return $app; |
1 2 3 4 5 6 7 8 | // public/index.php use Illuminate\Contracts\Http\Kernel; // 中略... $app = require_once __DIR__.'/../bootstrap/app.php'; // Service Containerからオブジェクトを取り出しているっぽい処理 $kernel = $app->make(Kernel::class); |
復習になりますが、Service Containerの役割は、Laravelアプリケーションで必要なオブジェクトを用意・提供することです。
上で読んだ処理は、まさに役割を体現したようなことが書かれています。
見えやすくなるよう該当する処理だけ抜き出してみます。
1 2 3 4 5 6 7 8 | // オブジェクトをどうやって用意するのか規定 $app->singleton( Illuminate\Contracts\Http\Kernel::class, App\Http\Kernel::class ); // Service Containerからオブジェクトを取り出す // ここでのKernelは、Illuminate\Contracts\Http\Kernel Interfaceを指す $kernel = $app->make(Kernel::class); |
Application::singleton()は、Kernelオブジェクトを要求されたとき、どのオブジェクトを用意するのか決めています。
そして、 Application::make()は、上の対応づけをもとに、オブジェクトを生成して呼び出し元に返しています。
オブジェクトを用意・提供している処理がどうやって実現されているのか見えてくれば、Service Containerが何をしているかも明らかにできそうです。
ということで、Service Containerを理解する一歩目として、オブジェクトの登録・取得処理の仕組みを探検してみます。
Service Containerの仕組み
Service Containerがどのように動いているのか、ざっくりと読み解いていきます。
まずは全体像を掴むために、やっていることを簡単に言葉にしておきます。
Service Containerは、自身のプロパティにオブジェクトをつくる方法を保存しておきます。
そして、インスタンスを要求されると、プロパティを参照し、オブジェクトを組み立てて返却します。
文字で書き出すとなんだか難しそうです。何をやっているのかもう少し見えやすくなるよう、それっぽいコードで動きを書き出してみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | // なんちゃってService Container class ServiceContainer { // オブジェクトのつくり方を格納 private array bindings[]; // オブジェクトのつくり方を決める public function set(string $abstract, string $concrete) { // キーに抽象的なクラス名を設定しておくことで、あとからキーでオブジェクトが取り出せるようになる $this->bindings[$abstract] = $concrete; } // つくり方に従い、オブジェクトを用意して返却 public function get(string $abstract) { return new $this->bindings[$abstract]; } } $app = new ServiceContainer(); // KernelInterfaceという名前のオブジェクトを要求されたら、具体的なクラスからオブジェクトをつくって返すよう指示 $app->set(KernelInteface::class, Kernel::class); // 要求をもとにオブジェクトを生成して返却 $kernel = $app->get(KernelInterface::class); // 得られたオブジェクトでアプリケーションの処理を実行 $kernel->handle(); |
オブジェクトのつくり方をあらかじめ決めておき、必要になったらつくって渡す。これがService Containerの主要な処理です。
それではLaravelでは具体的にどんなコードで実現しているのか、解き明かしていきましょう。
Container::singleton()-オブジェクトのつくり方を登録
app.phpでは、オブジェクトのつくり方を登録する処理として Container::singleton()を呼び出しています。
この処理がどうやって動作しているのか追ってみたいと思います。
1 2 3 4 5 | // bootstrap/app.php $app->singleton( Illuminate\Contracts\Http\Kernel::class, App\Http\Kernel::class ); |
まずはメソッド定義を入り口とします。
※ Service Containerとしての機能は、Applicationクラスの継承元である Illuminate\Container\Containerクラスに書かれています。よって、以降ではContainerクラスを中心に見ていきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 | // Illuminate/Container/Container.php /** * Register a shared binding in the container. * * @param string $abstract * @param \Closure|string|null $concrete * @return void */ public function singleton($abstract, $concrete = null) { $this->bind($abstract, $concrete, true); } |
Container::bind()へと続きます。
今回の場合、変数abstractはInterface名・concreteはオブジェクトをつくる対象の完全修飾クラス名・そして第3引数はオブジェクトをシングルトンとして共有することを表現しています。
Container::bind()
オブジェクトの生成方法を決定するメソッドを見てみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | /** * Register a binding with the container. * * @param string $abstract * @param \Closure|string|null $concrete * @param bool $shared * @return void * * @throws \TypeError */ public function bind($abstract, $concrete = null, $shared = false) { // 中略... // オブジェクトのつくり方が決まっていない場合、デフォルトの生成方法を取得 // If the factory is not a Closure, it means it is just a class name which is // bound into this container to the abstract type and we will just wrap it // up inside its own Closure to give us more convenience when extending. if (! $concrete instanceof Closure) { if (! is_string($concrete)) { throw new TypeError(self::class.'::bind(): Argument #2 ($concrete) must be of type Closure|string|null'); } $concrete = $this->getClosure($abstract, $concrete); } // オブジェクトの生成方法をbindingsプロパティへ保存しておく $this->bindings[$abstract] = compact('concrete', 'shared'); // 中略... } |
今回はクラス名の文字列だけを渡しているので、オブジェクトの生成方法はService Containerが規定しているデフォルトが設定されます。
デフォルトの設定方法は Container::getClosure()に定義されているので、中身を確認しておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | /** * Get the Closure to be used when building a type. * * @param string $abstract * @param string $concrete * @return \Closure */ protected function getClosure($abstract, $concrete) { // Container::resolve()を呼び出していると理解しておけばOK return function ($container, $parameters = []) use ($abstract, $concrete) { if ($abstract == $concrete) { return $container->build($concrete); } return $container->resolve( $concrete, $parameters, $raiseEvents = false ); }; } |
関数を返す関数でぱっと見難しそうですが、ひとまずはオブジェクトをつくるときに Container::resolve()を呼び出しているんだな、ということだけを覚えておきましょう。
1 2 | // オブジェクトの生成方法をbindingsプロパティへ保存しておく $this->bindings[$abstract] = compact('concrete', 'shared'); |
compact関数は変数名から配列を生成するためのものです。
参考
ですので、bindingsプロパティは以下のような構造となります。
1 2 3 4 5 6 | $bindings = [ 'Illuminate\Contracts\Http\Kernel::class' => [ 'concrete' => 'Container::resolve()を呼び出すClosure', 'shared' => true ] ]; |
つまり、 Container::bind()が呼ばれると、オブジェクトをどうやってつくるのかが決定されます。
Container::make()
app.phpで Container::singleton()を呼び出すことで、オブジェクトのつくり方が定まりました。
そして、呼び出し元のindex.phpで早速オブジェクトが必要になったので、 Container::make()でオブジェクトを取り出しています。
1 2 | // public/index.php $kernel = $app->make(Kernel::class); |
つくり方をもとに、Service Containerがどうやってオブジェクトを生成しているのか、探ってみましょう。
まずは例のごとくメソッド定義へ移動するところから始めます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | // Illuminate/Container/Container.php /** * Resolve the given type from the container. * * @param string|callable $abstract * @param array $parameters * @return mixed * * @throws \Illuminate\Contracts\Container\BindingResolutionException */ public function make($abstract, array $parameters = []) { return $this->resolve($abstract, $parameters); } |
引数abstractには、クラスの完全修飾名を表す文字列 Illuminate\Contracts\Http\Kernelが指定されています。
オブジェクトをつくるときの引数parametersは今回は空なので、気にしないでおきます。
さて、実際にオブジェクトを組み立てている Container::resolve()を読んでいきます。
Container::resolve()
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | /** * Resolve the given type from the container. * * @param string|callable $abstract * @param array $parameters * @param bool $raiseEvents * @return mixed * * @throws \Illuminate\Contracts\Container\BindingResolutionException * @throws \Illuminate\Contracts\Container\CircularDependencyException */ protected function resolve($abstract, $parameters = [], $raiseEvents = true) { // オブジェクトのつくり方を表すconcrete変数を設定 // 中略... $concrete = $this->getContextualConcrete($abstract); // 中略... if (is_null($concrete)) { $concrete = $this->getConcrete($abstract); } // concrete変数をもとにオブジェクトを生成 // We're ready to instantiate an instance of the concrete type registered for // the binding. This will instantiate the types, as well as resolve any of // its "nested" dependencies recursively until all have gotten resolved. if ($this->isBuildable($concrete, $abstract)) { $object = $this->build($concrete); } else { $object = $this->make($concrete); } // Container::singleton()経由でオブジェクトをつくった場合、1つのオブジェクトを全体で共有できるよう設定 // If the requested type is registered as a singleton we'll want to cache off // the instances in "memory" so we can return it later without creating an // entirely new instance of an object on each subsequent request for it. if ($this->isShared($abstract) && ! $needsContextualBuild) { $this->instances[$abstract] = $object; } // 中略 return $object; } |
少し長めの処理なので、段階的に見ていきます。
まず、 Container::resolve()の目的は、指定された情報(今回はクラス名)をもとにオブジェクトをつくって返すことです。
これを実現するために、binding、つまりつくり方を探し出し、得られたものに従ってオブジェクトを組み立てています。
それぞれの動作を簡単に見てみます。
オブジェクトのつくり方を読み出す-Container::getConcrete()
※ contextualConcreteなるものは、参照元に応じて返すオブジェクトを切り替えるための仕組みです。今回は関係しないことから割愛します。
concrete変数はnullと評価されるので、 Container::getConcrete()が呼ばれます。
このメソッドでやっていることは非常にシンプルで、 Container::bind()で登録したClosureを読み出しています。登録されたClosureはオブジェクトのつくり方を表しています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | /** * Get the concrete type for a given abstract. * * @param string|callable $abstract * @return mixed */ protected function getConcrete($abstract) { // If we don't have a registered resolver or concrete for the type, we'll just // assume each type is a concrete name and will attempt to resolve it as is // since the container should be able to resolve concretes automatically. if (isset($this->bindings[$abstract])) { return $this->bindings[$abstract]['concrete']; } return $abstract; } |
オブジェクトをつくる-Container::build()
つくり方を表すレシピが手元に揃ったので、いよいよオブジェクトをつくる処理を探ります。
ここから少し難しくなるので、流れを1つ1つじっくりと見ていきます。
1 2 3 4 5 6 7 8 9 10 11 | // concreteはオブジェクトを生成するためのClosure // abstractはつくりたいオブジェクトと対応するクラス名を表す // We're ready to instantiate an instance of the concrete type registered for // the binding. This will instantiate the types, as well as resolve any of // its "nested" dependencies recursively until all have gotten resolved. if ($this->isBuildable($concrete, $abstract)) { $object = $this->build($concrete); } else { $object = $this->make($concrete); } |
1 2 3 4 5 6 7 8 9 10 11 | /** * Determine if the given concrete is buildable. * * @param mixed $concrete * @param string $abstract * @return bool */ protected function isBuildable($concrete, $abstract) { return $concrete === $abstract || $concrete instanceof Closure; } |
Container::isBuildable()はconcrete(getConcreteメソッドで得られたもの)がClosureであることからtrueが返ります。
よって、インスタンスをつくる処理は、 Container::build()が主要な役割を担っています。
ということで、 Container::build()が何をしているか、明らかにしていきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | /** * Instantiate a concrete instance of the given type. * * @param \Closure|string $concrete * @return mixed * * @throws \Illuminate\Contracts\Container\BindingResolutionException * @throws \Illuminate\Contracts\Container\CircularDependencyException */ public function build($concrete) { // If the concrete type is actually a Closure, we will just execute it and // hand back the results of the functions, which allows functions to be // used as resolvers for more fine-tuned resolution of these objects. if ($concrete instanceof Closure) { return $concrete($this, $this->getLastParameterOverride()); } // 中略 } |
どうやら引数がClosureであった場合、呼び出してすぐに値を返してしまうようです。
この処理を詳細に読み解こうとすると、関数の中で呼ばれる関数の戻り値の戻り値を考えるようになり、非常に難しくなってしまいます。
よって、ここでは、最終的にどうなるのか結果だけを書いておきます。なぜこのような構造を持ち、何が起こっているのかは補足に譲ることにします。
一連の処理は最終的に、具体的なクラス名 App\Console\Kernelを引数に Container::build()を呼び出すことで元の処理に合流します。
補足: Closureが呼ばれてから元の処理に合流するまで何が起こっているのか
しっかりと理解しておきたい方のために、簡単に処理の流れを記しておきます。
まず、そもそも呼び出されるClosureがどのようなものであったか復習するところから始めます。
1 2 3 4 5 6 7 8 9 10 11 12 | // abstractはIlluminate\Contracts\Http\Kernel::class // concreteはApp\Http\Kernel::class protected function getClosure($abstract, $concrete) { return function ($container, $parameters = []) use ($abstract, $concrete) { // 中略 // ここでのconcreteは、クラス名App\Http\Kernel return $container->resolve( $concrete, $parameters, $raiseEvents = false ); }; } |
なんと、 Container::resolve()の中でさらに Container::resolve()が呼ばれています。
なんだか無限ループしそうに見えますが、実際には呼ばれるときの引数が異なります。
Closureで呼び出す Container::resolve()は、具象クラス名 App\Console\Kernelを引数とします。
一方、 Container::make()から呼ばれるときは、Interface名 Illuminate\Contracts\Console\Kernelが渡されます。
この違いは、 Container::build()へ渡す引数である、変数concreteを組み立てる処理に表れます。
変数concreteを生成しているメソッド Container::getConcrete()を見てみましょう。
1 2 3 4 5 6 7 8 9 10 11 | protected function getConcrete($abstract) { // If we don't have a registered resolver or concrete for the type, we'll just // assume each type is a concrete name and will attempt to resolve it as is // since the container should be able to resolve concretes automatically. if (isset($this->bindings[$abstract])) { return $this->bindings[$abstract]['concrete']; } return $abstract; } |
引数である具象クラス名 App\Console\Kernelはbindingsプロパティに登録されていないことから、そのまま戻り値となります。
すると、そのまま後続へと処理が進んでいき、 Container::build()がClosureではなく、具象クラス名 App\Console\Kernelを引数に呼ばれるようになります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | // Container::resolve()の一部 // concreteは文字列App\Console\Kernelとなる if (is_null($concrete)) { $concrete = $this->getConcrete($abstract); } // Container::isBuildable()は、concreteとabstractが同一でもtrueを返す // よって、文字列App\Console\Kernelを引数にContainer::build()が呼ばれる // We're ready to instantiate an instance of the concrete type registered for // the binding. This will instantiate the types, as well as resolve any of // its "nested" dependencies recursively until all have gotten resolved. if ($this->isBuildable($concrete, $abstract)) { $object = $this->build($concrete); } else { $object = $this->make($concrete); } |
補足: なぜこのような周りくどい仕組みが存在しているのか
Container::build()を見ていると、 Container::resolve()が2回呼ばれていることが分かりました。
なぜこのような周りくどい処理をしているのでしょうか。
単純に考えれば、以下のコードのようにClosureの中で Container::build()を呼べば済む話のように思えます。
1 2 3 4 5 6 7 8 9 10 | // abstractはIlluminate\Contracts\Http\Kernel::class // concreteはApp\Http\Kernel::class protected function getClosure($abstract, $concrete) { return function ($container, $parameters = []) use ($abstract, $concrete) { // 中略 // ここでのconcreteは、クラス名App\Http\Kernel return $container->build($concrete); }; } |
実は、Laravelのコードのコメントに経緯は書かれていました。該当箇所を見てみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | // Container::bind()を抜粋 // If the factory is not a Closure, it means it is just a class name which is // bound into this container to the abstract type and we will just wrap it // up inside its own Closure to give us more convenience when extending. // 変数concreteがClosureでないなら、それは抽象型に対する具象型である。 // 「extending」にて利便性を確保するために、Closureで包んでおく if (! $concrete instanceof Closure) { if (! is_string($concrete)) { throw new TypeError(self::class.'::bind(): Argument #2 ($concrete) must be of type Closure|string|null'); } $concrete = $this->getClosure($abstract, $concrete); } |
どうやら、「extending」なる処理の都合でこのような複雑な構造が必要であるようです。
詳細は参考リンクに譲りますが、既にできあがったオブジェクトを利用し、さらに処理を拡張したオブジェクトをつくることをextendingと呼ぶようです。
このとき、既存のオブジェクトを参照する上で、 Container::resolve()が既存のオブジェクトと対応するクラス名でも呼ばれるようになっていると、シンプルに扱えるようになります。
具体的には、以下のコードにて既存のオブジェクトが参照されます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | // Container::resolve()を抜粋 // 既存のオブジェクトを得る // We're ready to instantiate an instance of the concrete type registered for // the binding. This will instantiate the types, as well as resolve any of // its "nested" dependencies recursively until all have gotten resolved. if ($this->isBuildable($concrete, $abstract)) { $object = $this->build($concrete); } else { $object = $this->make($concrete); } // 既存のオブジェクトを引数に、拡張したオブジェクト生成処理(Closure)を呼び出す // If we defined any extenders for this type, we'll need to spin through them // and apply them to the object being built. This allows for the extension // of services, such as changing configuration or decorating the object. foreach ($this->getExtenders($abstract) as $extender) { $object = $extender($object, $this); } |
今度こそオブジェクトをつくる-Container::build()
さて、 Container::build()は呼び出す処理が少々複雑であることから回り道をしてしまいました。
ようやく本筋の処理に戻って来たので、改めて見るべきことを整理しておきます。
ここからは、 App\Console\Kernelオブジェクトがどうやってつくられるのか、たどっていきます。
まずはコードから流れを掴んでおきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 | /** * Instantiate a concrete instance of the given type. * * @param \Closure|string $concrete * @return mixed * * @throws \Illuminate\Contracts\Container\BindingResolutionException * @throws \Illuminate\Contracts\Container\CircularDependencyException */ public function build($concrete) { // concreteは文字列「App\Console\Kernel」 // 文字列で動的にクラスを操作するReflectionと呼ばれる仕組みを使えるようにする try { $reflector = new ReflectionClass($concrete); } catch (ReflectionException $e) { throw new BindingResolutionException("Target class [$concrete] does not exist.", 0, $e); } // 対象のクラスのコンストラクタを取得 $constructor = $reflector->getConstructor(); // コンストラクタが無いのであれば、シンプルにオブジェクトをつくって返却 // If there are no constructors, that means there are no dependencies then // we can just resolve the instances of the objects right away, without // resolving any other types or dependencies out of these containers. if (is_null($constructor)) { array_pop($this->buildStack); return new $concrete; } // コンストラクタの引数を解決 // 引数がクラスであれば再帰的に解決 $dependencies = $constructor->getParameters(); // Once we have all the constructor's parameters we can create each of the // dependency instances and then use the reflection instances to make a // new instance of this class, injecting the created dependencies in. try { $instances = $this->resolveDependencies($dependencies); } catch (BindingResolutionException $e) { array_pop($this->buildStack); throw $e; } // 最終的に、コンストラクタを引数つきで呼び出し、得られたオブジェクトを返却 return $reflector->newInstanceArgs($instances); } |
Container::build()の動作は一言でまとめると、動的にオブジェクトを生成することです。
動的にクラスを操作するために、Reflectionと呼ばれる仕組みを呼び出しています。
対象のクラスがコンストラクタで更にクラスを参照していると、少し処理が複雑になりますが、ここではひとまずクラス名をもとにオブジェクトをつくっているんだな、ということを押さえておきましょう。
戻り値を返すまで-Container::resolve()
Container::build()にて、欲しかったオブジェクトを手にいれることができました。
あとは呼び出し元に返すまでの流れを簡単に見ておきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | // Container::resolve()抜粋 // concrete変数をもとにオブジェクトを生成 // 変数$objectにつくられたオブジェクトが格納される // We're ready to instantiate an instance of the concrete type registered for // the binding. This will instantiate the types, as well as resolve any of // its "nested" dependencies recursively until all have gotten resolved. if ($this->isBuildable($concrete, $abstract)) { $object = $this->build($concrete); } else { $object = $this->make($concrete); } // Container::singleton()経由でオブジェクトをつくった場合、1つのオブジェクトを全体で共有できるよう設定 // If the requested type is registered as a singleton we'll want to cache off // the instances in "memory" so we can return it later without creating an // entirely new instance of an object on each subsequent request for it. if ($this->isShared($abstract) && ! $needsContextualBuild) { $this->instances[$abstract] = $object; } // 中略 return $object; |
注目すべきは、 Container::singleton()経由でオブジェクトを登録していた場合、Containerクラスのinstancesプロパティへオブジェクトを保存しているところです。
このことから、Service Containerはオブジェクトを取り出すとき、シングルトンである場合は一度つくったものを共有し、通常は新しくオブジェクトをつくって返していることが分かります。
Service Containerの概要ざっくりまとめ
とても長い道のりでしたが、ようやくService Containerの全体像が見えてきました。
忘れないよう理解したことを簡単にまとめておきましょう。
- Container::singleton()や Container::bind()でオブジェクトのつくり方をService Containerに保存しておく
- Container::make()が呼ばれると、つくり方に基づいてオブジェクトを生成
つくり方をあらかじめ決めておいて、必要になったらつくる。言葉にするとシンプルですね。
Service Containerのコンストラクタ
さて、Service Containerの仕組みを見てきたのは、コンストラクタで何をしているのか理解するためでした。
ここまでの道のりを思い出すために、見ていた処理をもう一度振り返ります。
1 2 3 4 5 6 7 | // エントリーポイントであるpublic/index.phpにてapp.phpを読込 $app = require_once __DIR__.'/../bootstrap/app.php'; // app.phpにて、Service Containerを表すクラスのインスタンスを生成 $app = new Illuminate\Foundation\Application( $_ENV['APP_BASE_PATH'] ?? dirname(__DIR__) ); |
これまでは、Service Containerの仕組みを理解するために、その先の処理である App\Http\Kernelオブジェクトをつくるところを見てきました。
仕組みが見えてくればApplicationクラスのコンストラクタも読めるようになっているはずです。
早速中身を覗いてみましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | // Illuminate/Foundation/Application.php // 先ほどまで見ていたContainerクラスを継承 class Application extends Container implements ApplicationContract, CachesConfiguration, CachesRoutes, HttpKernelInterface { use Macroable; /** * Create a new Illuminate application instance. * * @param string|null $basePath * @return void */ public function __construct($basePath = null) { if ($basePath) { $this->setBasePath($basePath); } $this->registerBaseBindings(); $this->registerBaseServiceProviders(); $this->registerCoreContainerAliases(); } |
コンストラクタで肝となるのは、registerから始まる3つのメソッドです。
それぞれが何をしているか把握できれば、Service Containerへ入門できたと思って良さそうです。
概要を探っていきます。
Application::registerBaseBinding()
ここでのbindingsは、オブジェクトまたはオブジェクトのつくり方を表します。汎用的な機能を表すオブジェクトをService Containerへ登録しておくのがメソッドの役目です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | /** * Register the basic bindings into the container. * * @return void */ protected function registerBaseBindings() { static::setInstance($this); // Container::instance()は、既存のインスタンスをinstancesプロパティへ設定し、Service Containerから参照できるようにする $this->instance('app', $this); $this->instance(Container::class, $this); $this->singleton(Mix::class); $this->singleton(PackageManifest::class, fn () => new PackageManifest( new Filesystem, $this->basePath(), $this->getCachedPackagesPath() )); } |
$this->singleton(Mix::class);のように引数が1つしかない場合、Service Containerのデフォルトの挙動にて、そのままオブジェクトがつくられます。
一方、PackageManifestクラスに関する設定は少し複雑そうです。何をやっているのか言葉にして整理しておきましょう。
第2引数がClosureであることから、bindings(インスタンスのつくり方)へそのまま登録されます。
$app->make(PackageManifest::class)のようにオブジェクトを取り出すタイミングにて、Closureが実行されます。
より具体的には、Closureに記述された方法でPackageManifestオブジェクトがつくられ、そのまま呼び出し元に返されます。
さまざまな呼び出し方を見ることで、Service Containerの仕組みも少しずつ見えてきたのではないでしょうか。
Application::registerCoreContainerAliases
※ Service Provider周りの話は長くなるので、先にこちらを見ておきます。
ここでの処理は、Service Containerに登録されたオブジェクトに別名をつけています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | /** * Register the core class aliases in the container. * * @return void */ public function registerCoreContainerAliases() { // Interfaceや継承元クラス名でもオブジェクトを参照できるようエイリアス(別名)を登録しておく foreach ([ 'app' => [self::class, \Illuminate\Contracts\Container\Container::class, \Illuminate\Contracts\Foundation\Application::class, \Psr\Container\ContainerInterface::class], // 中略... 'router' => [\Illuminate\Routing\Router::class, \Illuminate\Contracts\Routing\Registrar::class, \Illuminate\Contracts\Routing\BindingRegistrar::class], 'session' => [\Illuminate\Session\SessionManager::class], 'session.store' => [\Illuminate\Session\Store::class, \Illuminate\Contracts\Session\Session::class], 'url' => [\Illuminate\Routing\UrlGenerator::class, \Illuminate\Contracts\Routing\UrlGenerator::class], 'validator' => [\Illuminate\Validation\Factory::class, \Illuminate\Contracts\Validation\Factory::class], 'view' => [\Illuminate\View\Factory::class, \Illuminate\Contracts\View\Factory::class], ] as $key => $aliases) { foreach ($aliases as $alias) { $this->alias($key, $alias); } } } |
具体例で見てみましょう。
先ほど見ていた Application::registerBaseBinding()にて、appという名前でApplicationクラスのインスタンスを登録していました。
今回の処理と合わさると、以下のコードのように動作します。
1 2 3 4 5 | // $appはService Containerを指す $container = $app->make(\Illuminate\Contracts\Container\Container::class); $containerInterface = $app->make(\Psr\Container\ContainerInterface::class); // いずれも同一のApplicationオブジェクトが返却される |
別名をつけておくことで、Interface名など、ほかの識別子でもオブジェクトにアクセスできるようになります。
Application::registerBaseServiceProviders()
このメソッドは、 Application::register()を呼び出して各種Service Providerを設定しているようです。
1 2 3 4 5 6 7 8 9 10 11 | /** * Register all of the base service providers. * * @return void */ protected function registerBaseServiceProviders() { $this->register(new EventServiceProvider($this)); $this->register(new LogServiceProvider($this)); $this->register(new RoutingServiceProvider($this)); } |
Service Providerは、Service Containerが掴めていればサクッと理解できるはずです。
ということで、ここからはService Providerについて詳しく見ていきます。
Service Provider
Service ContainerとService Providerが連携している処理を見ていくことで、Service Providerの仕組みを解き明かしていきます。
上で見たコードでは3つのService Providerが登録されているようですが、今回はリクエストを扱う処理と関係が深そうなRoutingServiceProviderに絞って見ていきます。
復習-Service Providerとは
Service Providerの仕組みを見ていく前に、役割を簡単に復習しておきます。
Service Providerは、アプリケーションが動作するのに必要な機能を用意するのが役目です。具体的に何をしているのか、それっぽいコードから動きを確認しておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | // なんちゃってService Provider class ServiceProvider { // Service Containerを参照できるようにしておく private Application $app; public function __construct(Application $app) { $this->app = $app; } public function register() { // 必要なオブジェクトのつくり方をService Containerへ登録 $this->app->singleton(RouterInterface::class, Router::class); } } $serviceProvider = new ServiceProvider($app); // ServiceProvider::register()を呼ぶことで、アプリケーションが動作するのに必要な機能がServiceContainerへ用意される $serviceProvider->register(); |
Service Providerを通して、機能を表現するオブジェクトをService Containerへ登録しています。
こうしておくことで、Laravelアプリケーションが動作するための準備を整えることができます。
Application::register()
Service Providerの全体像が見えてきたところで、仕組みへと入り込んでいきます。
まずはService Providerを参照している Application::register()を見てみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | // Illuminate/Foundation/Application.php /** * Register a service provider with the application. * * @param \Illuminate\Support\ServiceProvider|string $provider * @param bool $force * @return \Illuminate\Support\ServiceProvider */ public function register($provider, $force = false) { // 中略... // Service Providerオブジェクトのregisterメソッドを呼び出す $provider->register(); // 中略... // Service Containerにて、後からboot処理(後述)を呼び出せるようService Providerを保持しておく $this->markAsRegistered($provider); // If the application has already booted, we will call this boot method on // the provider class so it has an opportunity to do its boot logic and // will be ready for any usage by this developer's application logic. if ($this->isBooted()) { $this->bootProvider($provider); } return $provider; } |
Application::register()の処理は、大きく2つに分かれています。
1つはbootと呼ばれる処理なのですが、入門段階ではあまり触れる機会が無さそうなので、補足へ譲ります。
重要なのは、もう1つの処理である、 ServiceProvider::register()を呼び出しているところです。
ServiceProvider::register()
ここでは、 ServiceProvider::register()が何をしているのか改めて見ていきます。具体例として、RoutingServiceProviderを対象とします。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | // Illuminate/Routing/RoutingServiceProvider.php class RoutingServiceProvider extends ServiceProvider { /** * Register the service provider. * * @return void */ public function register() { $this->registerRouter(); $this->registerUrlGenerator(); $this->registerRedirector(); // 中略... } // 中略... } |
RoutingServiceProvider::register()は、たくさんのregisterから始まるメソッドを呼び出しています。
今回は代表例として、一番上のメソッドだけを覗いておきます。
1 2 3 4 5 6 7 8 9 10 11 | /** * Register the router instance. * * @return void */ protected function registerRouter() { $this->app->singleton('router', function ($app) { return new Router($app['events'], $app); }); } |
Service Providerの役割の通り、Service ContainerへLaravelアプリケーションの機能を表現するオブジェクトのつくり方を設定しています。
繰り返しになりますが、Service Providerはひとまずは、Laravelアプリケーションの機能を表現するオブジェクトのつくり方を登録していくのが責務である。ということを頭に入れておきましょう。
補足: ServiceProvider::boot()について
Service Providerではもう1つ、bootなるメソッドが呼ばれるようになっています。
これは、Laravelの設定ファイルなどが読まれた後、つまりLaravelアプリケーションが動き出す準備が整ったときに呼び出されます。
あまり使う機会は多くありませんが、例えばほかのService Providerで登録されたオブジェクトで何か処理をしたいなど、自分自身以外と連携するときに有用です。
更に、今回見ていく処理で具体例を挙げると、 routes/web.phpに書いた Route::get()などで設定した情報を読み出すときにboot処理が関わっています。
ほかの機能と連携するための仕組みが用意されているんだな、ということだけまずは意識しておきましょう。
復習-Laravelが動く前準備が整うまで
さてさて、Laravelアプリケーションの準備段階で既に途方もない旅路となってしまいました。
ここからいよいよ実際にレスポンスを組み立てるところに移れるのですが、その前に来た道を振り返っておきましょう。
具体的には、Laravelアプリケーションのエントリーポイントから前準備が終わるまでを通しで見ていきます。
Service Container・Service Providerの役割が頭に入っていれば、きっと流れが掴めるはずです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | // public/index.php use Illuminate\Contracts\Http\Kernel; require __DIR__.'/../vendor/autoload.php'; $app = require_once __DIR__.'/../bootstrap/app.php'; // Service Containerからオブジェクトを取り出す $kernel = $app->make(Kernel::class); // これから見ていく処理 $response = $kernel->handle( $request = Request::capture() )->send(); |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | // bootstrap/app.php // Service Containerを用意 // このときに基本的な機能を表すオブジェクトがService Providerなどを通じてService Containerへ登録される $app = new Illuminate\Foundation\Application( $_ENV['APP_BASE_PATH'] ?? dirname(__DIR__) ); // Kernel Interfaceを実装したオブジェクトのつくり方を規定 $app->singleton( Illuminate\Contracts\Http\Kernel::class, App\Http\Kernel::class ); // Service Containerを読み込み元へ返却 /* |----------------------------------------------------------------------- | Return The Application |----------------------------------------------------------------------- | | This script returns the application instance. The instance is given to | the calling script so we can separate the building of the instances | from the actual running of the application and sending responses. | */ return $app; |
コードに書かれていることを箇条書きでも整理しておきましょう。
- Auto LoaderでPHPクラスを読み込む準備をしておく
- Service Containerを用意
- Laravelの基本的な機能をService Providerなどを介してService Containerへ登録
- Laravelアプリケーションの核となるKernelオブジェクトをService Containerから取り出せるよう設定
Laravelアプリケーションの準備段階の処理を見てきたことで、残すところ理解したいコードは以下の3行だけです。
1 2 3 | $response = $kernel->handle( $request = Request::capture() )->send(); |
当然、内部ではたくさんの処理が呼ばれているので、要点をかいつまんで少しずつ読み解いていきましょう。
Request::capture()
まずは、HTTPリクエストを表すオブジェクトをつくっている処理です。LaravelではどうやってHTTPリクエストを扱おうとしているのか、理解することを目指します。
見ていく処理は変わりましたが読み方は変わらず、メソッド定義へ移動するところから始めます。
1 2 3 4 5 6 7 8 9 10 11 12 13 | // Illuminate/Http/Request.php /** * Create a new Illuminate HTTP request from server variables. * * @return static */ public static function capture() { static::enableHttpMethodParameterOverride(); return static::createFromBase(SymfonyRequest::createFromGlobals()); } |
重要なのは、PHPDocに書かれている文です。
LaravelにおけるHTTPリクエストオブジェクトは、server variablesなるものからつくられているようです。
ここでのserver variablesは、 $_GETや $_POSTのようなWebサーバから受け取ったものを元に構築されているものを指します。
つまり、いわゆるPHPにおけるSuperglobalsから生のHTTPリクエストの内容を参照しています。
Symfonyとは
1 | SymfonyRequest::createFromGlobals() |
先ほどのコードにもあった通り、リクエストオブジェクトは、SymfonyRequestと名付けられたオブジェクトをもとにしているようです。
ゆえに、LaravelのHTTPリクエストオブジェクトがどのようなものであるか理解するには、Symfonyが何か明確にしておかなければなりません。
Symfonyそのものは、Laravelと同じくWebアプリケーションフレームワークです。
フレームワークの中で別のフレームワークをもとにしていると考えると、なんだか混乱してきそうです。もう少し詳しく見てみます。
LaravelとSymfonyの関係
Symfonyは、HTTPリクエストやRouterなど、Webアプリケーションに共通する要素を独立して扱えるよう切り出した、Symfony Componentsを提供しています。
参考
そしてLaravelでは、一部の機能をSymfony Componentsを拡張することで実現しています。
参考
まとめると、LaravelはHTTPリクエストオブジェクトを、Symfony Componentsとして提供されているものを拡張することで実装しているようです。
LaravelはSymfony Componentsを利用することで、いわゆる車輪の再発明を経ることなく、Webアプリケーションフレームワークとして必要な機能を実現しています。
SymfonyRequest::createFromGlobals()
Symfonyの正体が見えてきたので、呼ばれる処理を順に追いながら、リクエストオブジェクトがつくられる仕組みを見ていきます。
まずはSymfonyがどうやってHTTPリクエストオブジェクトをつくっているのか、俯瞰しておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 | // Symfony/Component/HttpFoundation/Request.php // ※ SymfonyRequestという名前は、Laravel側でSymfonyのRequestクラスを参照するときのエイリアス名 /** * Creates a new request with values from PHP's super globals. */ public static function createFromGlobals(): static { $request = self::createRequestFromFactory($_GET, $_POST, [], $_COOKIE, $_FILES, $_SERVER); // 中略... return $request; } |
Webサーバから渡される情報をもとにPHPが構築する変数Superglobalsから、リクエストオブジェクトを作成しています。
ここでは、リクエストオブジェクトがあることで、クエリ文字列やPOSTボディを扱いやすくなっているんだな、ということを押さえておきましょう。
Request::createFromBase()
Symfonyのリクエストオブジェクトは出来上がったので、続いてはLaravelが扱うリクエストオブジェクトへどうやって変換されていくのかを見ていきます。
流れを思い出すために、もう一度 Request::capture()を見直しておきます。
1 2 3 4 5 6 7 | public static function capture() { static::enableHttpMethodParameterOverride(); // Symfony RequestオブジェクトをもとにRequest::createFromBase()を呼び出す return static::createFromBase(SymfonyRequest::createFromGlobals()); } |
どうやらSymfonyが提供しているHTTPリクエストオブジェクトをベースに、Laravelが扱うHTTPリクエストオブジェクトをつくり出しているようです。
実際の処理の流れも確認しておきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | /** * Create an Illuminate request from a Symfony instance. * * @param \Symfony\Component\HttpFoundation\Request $request * @return static */ public static function createFromBase(SymfonyRequest $request) { // Symfonyのリクエストオブジェクトをもとに、Illuminate\Http\Requestオブジェクトを作成 $newRequest = (new static)->duplicate( $request->query->all(), $request->request->all(), $request->attributes->all(), $request->cookies->all(), $request->files->all(), $request->server->all() ); // 中略... return $newRequest; } |
クエリ文字列やクッキーといったHTTPリクエストに関する情報をSymfonyのリクエストオブジェクトから、Laravelのリクエストオブジェクトへ詰め替えています。
こうすることで、Symfony Componentsであるリクエストオブジェクトを拡張した、Laravelが扱うHTTPリクエストオブジェクトを手にいれることができます。
Kernel::handle
ここまでの処理で、アプリケーションを制御するKernelオブジェクトと、HTTPリクエストを表すリクエストオブジェクトがそろいました。
つまり、ようやくHTTPリクエストをもとにHTTPレスポンスを組み立てる処理を見ることができます。
1 2 3 4 | // public/index.php $response = $kernel->handle( $request = Request::capture() )->send(); |
ということで、 Kernel::handle()へと足を踏み入れていきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 | // Illuminate/Foundation/Http/Kernel.php class Kernel implements KernelContract { use InteractsWithTime; // これらのプロパティはService Containerにて設定される // Service Container /** * The application implementation. * * @var \Illuminate\Contracts\Foundation\Application */ protected $app; // URLと紐づく処理を探索するオブジェクト /** * The router instance. * * @var \Illuminate\Routing\Router */ protected $router; /** * Handle an incoming HTTP request. * * @param \Illuminate\Http\Request $request * @return \Illuminate\Http\Response */ public function handle($request) { try { $response = $this->sendRequestThroughRouter($request); } catch (Throwable $e) { $this->reportException($e); $response = $this->renderException($request, $e); } // 中略... return $response; } |
Kernel::handle()は、HTTPレスポンスオブジェクトをつくって返すのが責務のようです。レスポンス自体は、 Kernel::sendRequestThroughRouter()でRouterと呼ばれるオブジェクトを介して生成されています。
Routerがどんな役割を持つのか簡単に理解しておくために、今回アプリケーションコードとして書いたものを再度見てみます。
1 2 3 4 5 | // routes/web.php Route::get('/hello', function (Request $request) { // Hello Laravel from hello return "Hello Laravel from {$request->path()}"; }); |
これは、 http://localhost:8000/helloのようなURLへリクエストが送られると呼ばれる処理です。
Kernel::sendRequestThroughRouter()はリクエストのパスから呼び出すべき処理を決定し、実際に呼び出した上で得られたレスポンスを出力します。
上の例であれば、Routerから得られた戻り値である文字列 Hello Laravel from helloをよしなに加工してレスポンスオブジェクトへと変換しています。
Laravelの処理がどうやってアプリケーションのコードと合流してレスポンスを構築していくのか、仕組みを探っていきます。
Kernel::sendRequestThroughRouter()
Kernel::handle()から Kernel::sendRequestThroughRouter()へ移ります。
ここから更に難しくなってきますが、要所を押さえて読み解いていきましょう。まずはメソッドを読んでみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | /** * Send the given request through the middleware / router. * * @param \Illuminate\Http\Request $request * @return \Illuminate\Http\Response */ protected function sendRequestThroughRouter($request) { // リクエストオブジェクトをService Containerへ登録しておく $this->app->instance('request', $request); // 中略... $this->bootstrap(); return (new Pipeline($this->app)) ->send($request) ->through($this->app->shouldSkipMiddleware() ? [] : $this->middleware) ->then($this->dispatchToRouter()); } |
大きく2つの処理に分かれているので、分解して見ていきましょう。
Kernel::bootstrap()
まずはbootstrap処理です。単語自体は自動実行するということを意味しますが、Laravelでは起動するぐらいの意味で捉えておくとよいかもしれません。
Laravelにおけるbootstrapとは、Kernelクラスのbootstrappersプロパティに設定されたクラスのbootstrapメソッドを呼び出すことです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | // Kernelクラスのプロパティ /** * The bootstrap classes for the application. * * @var string[] */ protected $bootstrappers = [ \Illuminate\Foundation\Bootstrap\LoadEnvironmentVariables::class, \Illuminate\Foundation\Bootstrap\LoadConfiguration::class, \Illuminate\Foundation\Bootstrap\HandleExceptions::class, \Illuminate\Foundation\Bootstrap\RegisterFacades::class, \Illuminate\Foundation\Bootstrap\RegisterProviders::class, \Illuminate\Foundation\Bootstrap\BootProviders::class, ]; |
プロパティに設定されている完全修飾クラス名と対応するオブジェクトは、Service Containerを介してつくられています。
ここで、bootstrappersとして記述されたクラスは、 .envファイルを読み込んだり、configディレクトリ以下の設定値を読み出したりと、複雑なことをしています。
内部の仕組みが複雑であること・Hello World相当の処理では関わりが薄いことから、大半の処理は割愛します。
それぞれがざっくり何をしているかは、補足へ譲ることにします。
BootProviders
ここでは、以降の処理と関わりが深いBootProvidersだけを見ておきます。
とてもシンプルな処理なので、クラス全体を示します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | // Illuminate/Foundation/Bootstrap/BootProviders.php namespace Illuminate\Foundation\Bootstrap; use Illuminate\Contracts\Foundation\Application; class BootProviders { /** * Bootstrap the given application. * * @param \Illuminate\Contracts\Foundation\Application $app * @return void */ public function bootstrap(Application $app) { $app->boot(); } } |
Service Containerのbootメソッドを呼び出しています。具体的に何をしているのか、Service Containerを覗いてみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | // Illuminate/Foundation/Application.php /** * Boot the application's service providers. * * @return void */ public function boot() { // 中略... array_walk($this->serviceProviders, function ($p) { $this->bootProvider($p); }); $this->booted = true; // 中略... } /** * Boot the given service provider. * * @param \Illuminate\Support\ServiceProvider $provider * @return void */ protected function bootProvider(ServiceProvider $provider) { // 中略... if (method_exists($provider, 'boot')) { // Container::call()は非常に複雑なので割愛 // Service Providerのbootメソッドをよしなに呼び出していると解釈してOK $this->call([$provider, 'boot']); } } |
どうやらLaravelが起動(boot)するときには、Service Providerのbootメソッドを一斉に呼び出しているようです。
リクエストを処理する直前なので、Laravelを起動させてリクエストを扱う準備を整えるには丁度いいタイミングだと言えそうです。
補足: Kernel::bootstrap()では何が起きているのか
ここでは、BootProviders以外のbootstrapperが何をしているのか、概略を記しておきます。
Laravelのどういう処理がどこで動いているのか知っておくだけでも後々役に立つはずなので、ざっくりと押さえておきましょう。
LoadEnvironmentVariables
.envファイルを読み出すのが役割です。
最終的には file_get_contents()で.envファイル読み出して、対応するオブジェクトから参照できるようにしています。
LoadConfiguration
configディレクトリ以下の *.phpファイルをrequire命令で読み出しています。該当するファイルは、キーを設定名・値を設定値とする配列を返却しているので、この命令により設定を表す配列が得られます。
参考
Laravelアプリケーションで設定を参照するときは、上の処理で得られた配列から値を取り出しています。
HandleExceptions
Laravelアプリケーションで例外が起きたとき、どのクラスに任せるかを登録しています。対象は、 App\Exceptions\Handler.phpです。
このように設定しておくことで、Laravelアプリケーションで起きた例外を一律に制御できるようになります。
RegisterFacades
Route::get()のような記法にて、Service Containerに登録されたオブジェクトを参照するための仕組みを実現するFacadeクラスを準備します。Facadeの概要は後ほど触れていきます。
ひとまずは、Facadeクラスのクラス変数へService Containerを登録しているんだな、ぐらいのことを覚えておきましょう。
RegisterProviders
config/app.phpに書かれたServiceProviderを中心に、各種ServiceProviderを読み出しています。
読み出されるService Providerは、キャッシュやセッション・バリデーション処理など、リクエスト扱う上で重要な責務を担っています。
Pipelineとは
bootstrap処理でLaravelが動き出す準備が完全に整いました。
そうなると、残りの処理はリクエストからレスポンスを組み立てるのに大きく関わっているはずです。早速中身を見ていきたいところなのですが、なにやら難しそうな処理が書かれています。もう一度コードを見ておきましょう。
1 2 3 4 | return (new Pipeline($this->app)) ->send($request) ->through($this->app->shouldSkipMiddleware() ? [] : $this->middleware) ->then($this->dispatchToRouter()); |
Pipelineと呼ばれる仕組みで何かたくさんの処理が動いているようです。Pipelineとは一体どういうもので、何をしているのでしょうか。
pipelineという単語は、ガスなどを輸送するパイプを意味しています。Google画像検索なんかで見てみるとイメージしやすいかもしれません。
LaravelにおけるPipelineは、処理を繋げる役目を持っています。
Pipelineは何をしているのか
本来であればPipelineクラスのコンストラクタから始めて各メソッドを読んでいきたいところです。
しかし、Pipelineクラスは、おそろしいほど複雑な処理が書かれており、仕組みを解き明かすだけでも大変な労力を要します。
よってここでは、LaravelにおけるPipelineオブジェクトが何をしているのか、動作を簡単に記しておくに留めておきます。
一言で表すと、Pipelineオブジェクトは、複数のオブジェクトのメソッドを共通の引数でどんどん呼び出すように動きます。これだけではイメージしづらいので、上で見た処理を簡易版のクラスで再現してみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | // なんちゃってPipelineクラス // ※ 実際の仕組みをかなり簡略化しているので、雰囲気を掴む程度に眺めてください class Pipeline { private mixed $passable; // send()で共通の引数を設定 public function send(mixed $passable) { $this->passable = $passable; return $this; } // 共通の引数で一連のメソッドを呼び出す public function through(array $pipes) { foreach($pipes as $pipe) { $pipe->handle($this->passable); } return $this; } // 後処理として、渡されたClosureを呼び出す public function then(Closure $destination) { $destination($this->passable): } } $pipeline = new Pipeline($this->app); $pipeline = $pipeline->send($request); $pipeline = $pipeline->through($this->middleware) $pipeline->then($this->dispatchToRouter()); |
リクエストオブジェクトを引数に、ミドルウェア(後述)なるオブジェクトのhandleメソッドをどんどん呼び出します。そして、後処理として、 Kernel::dispatchToRouter()が呼ばれています。
ざっくり抜き出してみると、やっていることはシンプルですね。
このように、一定の入力を複数のハンドラで処理していく仕組みは、デザインパターンにてChain of Responsibilityパターンと命名されています。
もう少し詳しく知りたい方は参考リンクを読んでみてください。
参考
補足: ミドルウェアについて
ミドルウェアはHello Worldの段階ではあまり意識することはありませんが、せっかくなので少しだけ触れておきます。
参照されるミドルウェアは、 App\Http\Kernel.phpに書かれています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | namespace App\Http; use Illuminate\Foundation\Http\Kernel as HttpKernel; class Kernel extends HttpKernel { /** * The application's global HTTP middleware stack. * * These middleware are run during every request to your application. * * @var array */ protected $middleware = [ \App\Http\Middleware\TrustHosts::class, \App\Http\Middleware\TrustProxies::class, \Illuminate\Http\Middleware\HandleCors::class, \App\Http\Middleware\PreventRequestsDuringMaintenance::class, \Illuminate\Foundation\Http\Middleware\ValidatePostSize::class, \App\Http\Middleware\TrimStrings::class, \Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class, ]; // 中略... } |
これらのクラスの完全修飾名は、Service Containerを介してオブジェクトへと変換されます。
そして、ここに書かれているミドルウェアと名付けられたオブジェクトは、ミドル(中間)という名の通り、リクエストの前処理を担っています。
例えば、ValidatePostSizeクラスは、POSTリクエストのボディのサイズを事前に検証しておき、極端に大きなリクエストを扱わないようガードする役割を担っています。
具体的な実装もさらっと見ておきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | // ミドルウェア class ValidatePostSize { /** * Handle an incoming request. * * @param \Illuminate\Http\Request $request * @param \Closure $next * @return mixed * * @throws \Illuminate\Http\Exceptions\PostTooLargeException */ public function handle($request, Closure $next) { // POSTリクエストのボディの最大サイズ $max = $this->getPostMaxSize(); // POSTリクエストのボディが最大サイズを超過していたら処理を打ち止め if ($max > 0 && $request->server('CONTENT_LENGTH') > $max) { throw new PostTooLargeException; } // ※ 厳密にはPipelineにおける後続の処理は、オブジェクトのメソッドから呼び出されている return $next($request); } } |
入門段階では、ミドルウェアはリクエストオブジェクトを受け取って前処理をよしなにやっているんだな、ということを押さえておきましょう。
Kernel::dispatchToRouter
色々と回り道をしてきましたが、ようやくリクエストからレスポンスを組み立てる処理へたどり着きました。
本命の処理が何をしているのか、読んでいきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 | // Illuminate/Foundation/Http/Kernel.php /** * Get the route dispatcher callback. * * @return \Closure */ protected function dispatchToRouter() { return function ($request) { return $this->router->dispatch($request); }; } |
プロパティrouterは、Service Containerを介して渡された Illuminate\Routing\Routerオブジェクトです。
Routerはその名の通り、リクエストのURLをもとに対応する処理へと遷移先を振り分けるのが役割です。どうやって振り分けているのか、 Router::dispatch()から見てみます。
Router::dispatch
Kernelクラスから離れて、Routerクラスを探っていきます。
まずはdispatchメソッドの定義から始めていきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | // Illuminate/Routing/Router.php /** * Dispatch the request to the application. * * @param \Illuminate\Http\Request $request * @return \Symfony\Component\HttpFoundation\Response */ public function dispatch(Request $request) { $this->currentRequest = $request; return $this->dispatchToRoute($request); } // 中略... /** * Dispatch the request to a route and return the response. * * @param \Illuminate\Http\Request $request * @return \Symfony\Component\HttpFoundation\Response */ public function dispatchToRoute(Request $request) { return $this->runRoute($request, $this->findRoute($request)); } |
戻り値がHTTPレスポンスっぽいオブジェクトであることから、 Router::findRoute()で呼び出すべき処理を決め、 Router::runRoute()でHTTPレスポンスを生成しているように見えます。
それぞれの仕組みを見ていけば、HTTPレスポンスがどうやってつくられるのか明らかになりそうです。
順に整理していきます。
Router::findRoute()
最初に、呼び出す処理を決めているメソッドを読んでいきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 | /** * Find the route matching a given request. * * @param \Illuminate\Http\Request $request * @return \Illuminate\Routing\Route */ protected function findRoute($request) { // 中略... $this->current = $route = $this->routes->match($request); return $route; } |
リクエストのURLと合致するものとして、Routeなるオブジェクトを探し出しているようです。
ここで、Routeについて少し掘り下げていこうと思います。
Route
Routeという文字を見ると、Hello Worldアプリケーションとして実装したコードが思い浮かぶかもしれません。
復習がてら、アプリケーションの実装コードとして書いたものを見てみましょう。
1 2 3 4 5 | // routes/web.php Route::get('/hello', function (Request $request) { // Hello Laravel from hello return "Hello Laravel from {$request->path()}"; }); |
Routeクラスのgetメソッドなる静的メソッドを呼び出しているっぽい処理が書かれています。これはRouteオブジェクトと関係が深そうです。
ここで、先ほどまで見ていたRouterオブジェクトとの関係を考えると、いくつか疑問が浮かんできます。
- routes/web.phpで書かれたRouteとは何か
- いつroutes/web.phpは呼ばれたのか
- Route::get()が呼ばれると何が起こっているのか
Routerが何をしているのか理解するためには、これらの疑問を解消しておいた方が良さそうです。1つ1つざっくりと考えてみましょう。
RouteクラスとFacadeクラス
routes/web.phpで書かれたRouteクラスは、完全修飾名が Illuminate\Support\Facades\Routeとなっています。
Facadeなる概念が新しく登場しました。Facadeも掘り下げていくと深みにハマってしまうので、ここでは概要だけ触れておきます。
Facadeはデザインパターンの1つで、フレームワークなどの機能をシンプルに扱うためのインタフェースを提供します。
参考
これが何を表すかは、Facadeクラスの仕組みを知ることで見えてくるはずです。
深入りしすぎない程度にたどっていきましょう。
Facade
LaravelにおけるFacadeの仕組みを明らかにしていきます。
入り口はFacadeの1つであるRouteクラスとします。どのような構造を持つのか見てみましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 | // Illuminate/Support/Facades/Route.php class Route extends Facade { /** * Get the registered name of the component. * * @return string */ protected static function getFacadeAccessor() { return 'router'; } } |
Route::get()が呼ばれているはずなのに、getメソッドが定義されていません。親クラスにも定義は無さそうです。
どういう仕組みで何を呼び出しているのでしょうか。
実は、継承元であるFacadeクラスにて、 __callStatic()なるメソッドが定義されています。
これはPHPが特定のタイミングにて呼び出すメソッドで、 Route::get()のように静的メソッドを呼び出そうとして対象が見つからなかったときに発火します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | /** * Handle dynamic, static calls to the object. * * @param string $method * @param array $args * @return mixed * * @throws \RuntimeException */ public static function __callStatic($method, $args) { $instance = static::getFacadeRoot(); // 中略... return $instance->$method(...$args); } |
ということで、 __callStatic()から呼ばれている処理を見てみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | /** * Get the root object behind the facade. * * @return mixed */ public static function getFacadeRoot() { // getFacadeAccessorは子クラスに定義されている // 今回の場合は、文字列routerへと評価される return static::resolveFacadeInstance(static::getFacadeAccessor()); } /** * Resolve the facade root instance from the container. * * @param string $name * @return mixed */ protected static function resolveFacadeInstance($name) { // 中略... // クラス変数appは、bootstrapperにてService Containerが設定されている if (static::$app) { // 中略... return static::$app[$name]; } } |
中身を読んでみると、どうやらService Containerへ routerというキーで配列アクセスをしているようです。
Service ContainerであるContainerクラスは、ArrayAccess Interfaceを実装しているので、 Container::offsetGet()が呼ばれます。
参考
Container::offsetGet()は、オブジェクトを取り出す処理である Container::make()を呼んでいます。
1 2 3 4 5 6 7 8 9 10 11 | // Illuminate\Container\Container.php /** * Get the value at a given offset. * * @param string $key * @return mixed */ public function offsetGet($key): mixed { return $this->make($key); } |
つまりここまでの処理は、Service Containerからrouterというキーのオブジェクトを取り出すのが目的のようです。
routerというキーでオブジェクトを登録する処理は、 Application::registerBaseServiceProviders()から呼ばれるRoutingServiceProviderにて定義されています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | // Illuminate\Routing\RoutingServiceProvider.php class RoutingServiceProvider extends ServiceProvider { // 中略... /** * Register the router instance. * * @return void */ protected function registerRouter() { $this->app->singleton('router', function ($app) { return new Router($app['events'], $app); }); } } |
ここでのRouterは、先ほどまで見ていた Illuminate\Routing\Routerクラスを指しています。
少し長くなってしまいましたが、LaravelにおけるFacadeクラスは、デザインパターンで定義されている通り、Service Containerへ簡潔にアクセスするためのインタフェースを提供しているようです。
具体的には、 Route::get()のように書くだけで、Service Containerに登録されたRouterオブジェクトのメソッドが呼び出せるようになります。
routes/web.phpはいつ読み出されるのか
Facadeの仕組みを見ることで、 routes/web.phpがRouterと関わりが深いことが分かりました。
ですが、これまで見てきた処理でこのファイルは読み出されていませんでした。
重要な処理である以上どこかで読み出されてはいそうですが、一体どこで参照されたのでしょうか。
実は、Service Providerの1つである、 App\Providers\RouteServiceProviderクラスが入り口となっています。
※ このService Providerは config/app.phpに定義されているので、 Kernel::bootstrap()にて呼び出されています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | // App/Providers/RouteServiceProvider.php class RouteServiceProvider extends ServiceProvider { /** * Define your route model bindings, pattern filters, and other route configuration. */ public function boot(): void { $this->configureRateLimiting(); $this->routes(function () { Route::middleware('api') ->prefix('api') ->group(base_path('routes/api.php')); Route::middleware('web') ->group(base_path('routes/web.php')); }); } } |
ここの処理は非常に複雑なので、とりあえず routes/web.phpはService Providerを介して読み出され、実行されている。ということを頭に入れておきましょう。
Route::get()は何をしているのか
たくさん寄り道をしてしまったので、本来の目的を整理しておきます。
今回の目的は、Routerから参照されているRouteなるオブジェクトがどのようにつくられているのか明らかにすることです。
ということで、関わりが深そうな Route::get()へと戻ります。
1 2 3 4 | // routes/web.php Route::get('/greeting', function () { return 'Hello World'; }); |
ここでのRouteの実体はRouterオブジェクトであるため、実際には Router::get()が呼び出されます。
何が起きているのか掘り下げていきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | // Illuminate/Routing/Router.php /** * Register a new GET route with the router. * * @param string $uri * @param array|string|callable|null $action * @return \Illuminate\Routing\Route */ public function get($uri, $action = null) { return $this->addRoute(['GET', 'HEAD'], $uri, $action); } /** * Add a route to the underlying route collection. * * @param array|string $methods * @param string $uri * @param array|string|callable|null $action * @return \Illuminate\Routing\Route */ public function addRoute($methods, $uri, $action) { return $this->routes->add($this->createRoute($methods, $uri, $action)); } |
Router::addRoute()に注目してみます。
Routerが参照しているRouteオブジェクトをつくっている処理にたどり着けました。
ここを見ていけば、Routeオブジェクトが何者であるか理解できそうです。
先に進んでみましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | /** * Create a new route instance. * * @param array|string $methods * @param string $uri * @param mixed $action * @return \Illuminate\Routing\Route */ protected function createRoute($methods, $uri, $action) { // 中略... $route = $this->newRoute( $methods, $this->prefix($uri), $action ); // 中略... return $route; } /** * Create a new Route object. * * @param array|string $methods * @param string $uri * @param mixed $action * @return \Illuminate\Routing\Route */ public function newRoute($methods, $uri, $action) { return (new Route($methods, $uri, $action)) ->setRouter($this) ->setContainer($this->container); } |
ここで、methodsはGETまたはHEAD・uriは Route::get()に渡したパス・actionは Route::get()に渡したClosureを表しています。
Routeクラスもさわりだけ見ておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | // Illuminate/Routing/Route.php /** * Create a new Route instance. * * @param array|string $methods * @param string $uri * @param \Closure|array $action * @return void */ public function __construct($methods, $uri, $action) { $this->uri = $uri; $this->methods = (array) $methods; $this->action = Arr::except($this->parseAction($action), ['prefix']); // 中略... } |
ひとまずはプロパティに引数で渡したものを保存しているぐらいに理解しておきましょう。
さて、ようやくRouteオブジェクトが何者であるか理解できました。
理解したことを整理しておくと、Routeオブジェクトは、 routes/web.phpに書かれた Route::get()のようなメソッドを介してつくられます。
そして、Routeオブジェクトはパスと実行する処理(Closure)を保存しています。
Router::findRoute()
Routeオブジェクトが見えてくると、以降の処理で何をするかも明確になります。
リクエストのパスと対応するRouteオブジェクトさえ手に入れば何を実行するべきかも定まるので、レスポンスまで一気に繋げることができます。
ということで、 Router::findRoute()でどうやってRouteオブジェクトを探し当てるのか、解き明かしていきましょう。
復習のためにメソッド定義をもう一度見ておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | // Illuminate/Routing/Router.php /** * Find the route matching a given request. * * @param \Illuminate\Http\Request $request * @return \Illuminate\Routing\Route */ protected function findRoute($request) { // 中略... // routesプロパティは、Illuminate\Routing\RouteCollectionオブジェクトを指す $this->current = $route = $this->routes->match($request); return $route; } // Service Containerを介して呼ばれるコンストラクタ // routesプロパティを設定している /** * Create a new Router instance. * * @param \Illuminate\Contracts\Events\Dispatcher $events * @param \Illuminate\Container\Container|null $container * @return void */ public function __construct(Dispatcher $events, Container $container = null) { $this->events = $events; $this->routes = new RouteCollection; $this->container = $container ?: new Container; } |
該当するRouteオブジェクトを探す処理は、RouteCollectionオブジェクトが担っているようです。
※ 各Routeオブジェクトは、 Route::get()にてRouteCollectionオブジェクトへ詰め込まれています。
RouteCollection::match()
RouteCollectionオブジェクトがどうやってパスと対応するRouteオブジェクトを探しているのか、メソッドから仕組みを見てみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 | // Illuminate/Routing/RouteCollection.php /** * Find the first route matching a given request. * * @param \Illuminate\Http\Request $request * @return \Illuminate\Routing\Route * * @throws \Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException * @throws \Symfony\Component\HttpKernel\Exception\NotFoundHttpException */ public function match(Request $request) { // Routeオブジェクトのうち、HTTPメソッドがリクエストと一致しているもので絞り込む $routes = $this->get($request->getMethod()); // パスと対応するRouteオブジェクトを探索 // First, we will see if we can find a matching route for this current request // method. If we can, great, we can just return it so that it can be called // by the consumer. Otherwise we will check for routes with another verb. $route = $this->matchAgainstRoutes($routes, $request); // 「/user/{id}」のようなRouteパラメータをRouteオブジェクトで解釈しておく // 今回はRouteパラメータを扱わないので割愛 return $this->handleMatchedRoute($request, $route); } /** * Determine if a route in the array matches the request. * * @param \Illuminate\Routing\Route[] $routes * @param \Illuminate\Http\Request $request * @param bool $includingMethod * @return \Illuminate\Routing\Route|null */ protected function matchAgainstRoutes(array $routes, $request, $includingMethod = true) { // Routeオブジェクトのmatchesメソッドを呼び出し、最初にtrueを返したものを返却 [$fallbacks, $routes] = collect($routes)->partition(function ($route) { return $route->isFallback; }); return $routes->merge($fallbacks)->first( fn (Route $route) => $route->matches($request, $includingMethod) ); } |
重要なのは、 Route::matches()がtrueを返したRouteオブジェクトを返却していることです。
つまり、Routeオブジェクトでどのように判定しているかが分かれば、パスからどうやって呼び出すべき処理を決定しているのかが見えてきます。
ということで、 Route::matches()が何をやっているのか探っていきましょう。
Route::matches()
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | // Illuminate/Routing/Route.php /** * Determine if the route matches a given request. * * @param \Illuminate\Http\Request $request * @param bool $includingMethod * @return bool */ public function matches(Request $request, $includingMethod = true) { // 中略... foreach (self::getValidators() as $validator) { if (! $validator->matches($this, $request)) { return false; } } return true; } |
Route::getValiators()は、validatorと呼ばれるオブジェクトを取得する処理です。
validatorはbool値を返すmatchesというメソッドを実装しているので、すべてのvalidatorが有効だと判定したRouteオブジェクトが返されるようです。
ここでは、パスと関わりが深いUriValidatorクラスを見てみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | // Illuminate/Routing/Matching/UriValidator.php class UriValidator implements ValidatorInterface { /** * Validate a given rule against a route and request. * * @param \Illuminate\Routing\Route $route * @param \Illuminate\Http\Request $request * @return bool */ public function matches(Route $route, Request $request) { $path = rtrim($request->getPathInfo(), '/') ?: '/'; return preg_match($route->getCompiled()->getRegex(), rawurldecode($path)); } } |
何やら難しそうな処理が書かれていますが、ここではリクエストのパスとRouteオブジェクトに登録されたパスをよしなに比べているんだな、と思っておきましょう。
Router::findRoute()
ざっくり探っていくことで、何が起きているのか見えてきました。
理解を整理するために、 Router::findRoute()の流れをまとめておきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | // Illuminate/Routing/Router.php /** * Find the route matching a given request. * * @param \Illuminate\Http\Request $request * @return \Illuminate\Routing\Route */ protected function findRoute($request) { // 中略... $this->current = $route = $this->routes->match($request); return $route; } |
処理の流れが見えやすいよう、箇条書きで簡単に振り返っておきます。
- routes/web.php`などで`Route::get()のような処理を呼び出す
- パスと実行する処理を表すRouteオブジェクトを登録
- Routeオブジェクトは、RouteCollectionオブジェクトによって保持される
- RouteCollectionオブジェクトは、HTTPリクエストのメソッドやパスの情報をもとにRouteオブジェクトのmatchesメソッドを呼び出す
- それぞれのRouteオブジェクトは、パスなどの情報をもとに、自身でリクエストを処理するべきか判定
- 合致したものが返され、 Route::findRoute()の戻り値となる
ということでまとめると、パスが合致するRouteオブジェクトを探し出すのが Router::findRoute()の責務だったようです。
Router::runRoute()
Router::findRoute()により、実行するべき処理に対応するRouteオブジェクトが得られました。
あとはリクエストを扱う処理を呼び出せばレスポンスが手に入るはずです。流れを見返すために、 Router::findRoute()を呼び出しているところを見直しておきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 | // Illuminate/Routing/Router.php /** * Dispatch the request to a route and return the response. * * @param \Illuminate\Http\Request $request * @return \Symfony\Component\HttpFoundation\Response */ public function dispatchToRoute(Request $request) { return $this->runRoute($request, $this->findRoute($request)); } |
リクエストオブジェクトと、 Router::findRoute()`で得られたRouteオブジェクトを引数に、`Router::runRoute()を呼び出しているようです。
Router::runRoute()の仕組みが明確になれば、リクエストからレスポンスを組み立てるまでの処理の流れが繋がるはずです。
最後の正念場となりそうですが、じっくりと見ていきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | /** * Return the response for the given route. * * @param \Illuminate\Http\Request $request * @param \Illuminate\Routing\Route $route * @return \Symfony\Component\HttpFoundation\Response */ protected function runRoute(Request $request, Route $route) { // 中略... return $this->prepareResponse($request, $this->runRouteWithinStack($route, $request) ); } |
再び処理が2つに分かれているようです。メソッド名を見るに、 Router::runRouteWithinStack()`でレスポンスの元になるオブジェクトを組み立て、`Router::prepareResponse()でHTTPレスポンスを表すオブジェクトへと変換しているように思えます。
ということなので、まずはレスポンスの元をつくっていそうな Router::runRouteWithinStack()を見ていきます。
Router::runRouteWithinStack()
長そうなメソッド名ですが、ひとまず定義から概要を俯瞰しておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | /** * Run the given route within a Stack "onion" instance. * * @param \Illuminate\Routing\Route $route * @param \Illuminate\Http\Request $request * @return mixed */ protected function runRouteWithinStack(Route $route, Request $request) { // 中略... $middleware = $shouldSkipMiddleware ? [] : $this->gatherRouteMiddleware($route); return (new Pipeline($this->container)) ->send($request) ->through($middleware) ->then(fn ($request) => $this->prepareResponse( // 今回見るべき処理は、Route::run()のみ $request, $route->run() )); } |
ここでのミドルウェアは、Routeオブジェクトに挟まるものなのですが、入門段階ではあまり触れる機会も無いので割愛します。
Pipelineで書かれた処理は、ミドルウェアの処理を実行した上で後処理を動かすためのものです。
今回見るべきは、Routeオブジェクトと結びつく処理を呼び出していると思われる Route::run()です。
Routeオブジェクトと結びつく処理は、 routes/web.phpで定義したものです。肝となる重要な処理なので、再掲しておきます。
1 2 3 4 5 6 | // routes/web.php // 呼び出されるのは、Route::get()の第二引数のClosure Route::get('/hello', function (Request $request) { // Hello Laravel from hello return "Hello Laravel from {$request->path()}"; }); |
このClosureがどうやって呼び出されるのか理解することを目指します。
Route::run()
ということで、Routeオブジェクトへと移動します。
Route::run()が何をしているのか見ていきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | // Illuminate/Routing/Route.php /** * Run the route action and return the response. * * @return mixed */ public function run() { // 中略... try { return $this->runCallable(); } catch (HttpResponseException $e) { return $e->getResponse(); } } |
Route::runCallable()へと進みます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | /** * Run the route action and return the response. * * @return mixed */ protected function runCallable() { // Route::get()で渡したClosureと等価 $callable = $this->action['uses']; // 中略... // Service Containerからキー「Illuminate\Routing\Contracts\CallableDispatcher」でオブジェクトを取り出す // 取り出したオブジェクトのdispatchメソッドを、Routeオブジェクト、呼び出すClosureを引数に実行 return $this->container[CallableDispatcher::class]->dispatch($this, $callable); } |
ここからはじっくり整理していく必要がありそうです。
1つ1つの処理が何をしているのかゆっくり解き明かしていきましょう。
CallableDispatcher
Service Containerから取り出そうとしていたCallableDispatcherオブジェクトは、Service Containerの初期処理で実行されるRoutingServiceProviderにて用意されています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | // Illuminate/Routing/RoutingServiceProvider.php /** * Register the callable dispatcher. * * @return void */ protected function registerCallableDispatcher() { // CallableDispatcherContractは、CallableDispatcher Interfaceのエイリアス $this->app->singleton(CallableDispatcherContract::class, function ($app) { return new CallableDispatcher($app); }); } |
ここで生成されるオブジェクトは、 Illuminate\Routing\CallableDispatcherオブジェクトです。
ということで、Service Containerから何を取り出しているのか見えてきました。
続いて、取り出されたオブジェクトのdispatchメソッドで何が起きているのか見ていきます。
CallableDispatcher::dispatch()
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | // Illuminate/Routing/CallableDispatcher.php /** * Dispatch a request to a given callable. * * @param \Illuminate\Routing\Route $route * @param callable $callable * @return mixed */ public function dispatch(Route $route, $callable) { // 変数callableはRoute::get()で渡したClosure return $callable(...array_values($this->resolveParameters($route, $callable))); } |
ついに Route::get()で渡した処理を呼び出している箇所へたどり着きました。
最後に明らかにしなければならないのは、どうやって引数を組み立てているかです。ここで渡されるClosureは、リクエストオブジェクトを引数として受け取っています。
よって、 CallableDispatcher::resolveParameters()にて、なんらかの仕組みで引数であるオブジェクトを構築しているはずです。
ここは難解な処理が書かれているので、全体像を掴むぐらいを目指して見ていきます。
CallableDispatcher::resolveParameters()
まずはメソッド定義を見てみます。
1行の処理ですがたくさんのことが詰まっているので、じっくり解きほぐしていきましょう。
1 2 3 4 5 6 7 8 9 10 11 | /** * Resolve the parameters for the callable. * * @param \Illuminate\Routing\Route $route * @param callable $callable * @return array */ protected function resolveParameters(Route $route, $callable) { return $this->resolveMethodDependencies($route->parametersWithoutNulls(), new ReflectionFunction($callable)); } |
まず、 Route::parametersWithoutNulls()`は、`/user/{id}のようなパスから組み立てられた引数を抜き出す処理です。
参考
このようなパラメータは今回は扱わないので割愛します。
続いて、ReflectionFunctionオブジェクトをつくっている処理は、関数が受け取る引数を読み出すためのものです。
Route::get()に渡した処理を例に考えると、Request型のオブジェクトを引数として受け取ることが読み出されます。
これらの前提を踏まえた上で、Closureへ渡す引数を組み立てる処理 CallableDispatcher::resolveMethodDependencies()を読んでいきましょう。
CallableDispatcher::resolveMethodDependencies()
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | /** * Resolve the given method's type-hinted dependencies. * * @param array $parameters * @param \ReflectionFunctionAbstract $reflector * @return array */ public function resolveMethodDependencies(array $parameters, ReflectionFunctionAbstract $reflector) { // 中略... // Closureが受け取る引数を1つ1つ走査 // keyはインデックス // parameterは引数そのものを表すReflectionParameterオブジェクトとなる foreach ($reflector->getParameters() as $key => $parameter) { // 引数の情報からインスタンスをつくっていそうな処理 $instance = $this->transformDependency($parameter, $parameters, $skippableValue); // 中略... $this->spliceIntoParameters($parameters, $key, $instance); } return $parameters; } |
難しそうな処理が並んでいます。一気に理解しようと思うと迷子になってしまうので、まずは何をやっているのかざっくり掴むことを目指します。
そこで、処理が何をしているのか簡易版のコードで眺めておきます。
1 2 3 4 5 6 7 8 9 10 | // 呼び出すClosure function resolveRequest(Request $request) { return "Hello Laravel from {$request->path()}"; } // transformDependency()でClosureを呼び出すための引数となるオブジェクトを取得 $request = transformDependency(Request::class); // 得られたオブジェクトを引数にClosureを呼び出す $response = resolveRequest($request); |
Reflectionの仕組みが関わることで難しく見えますが、ざっくりやっていることは、関数定義をもとに引数を組み立てているのみです。
よって、どうやって引数となるオブジェクトを組み立てているのか、流れを押さえておきましょう。
CallableDispatcher::transformDependency()
オブジェクトをつくっていそうな処理を見てみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | /** * Attempt to transform the given parameter into a class instance. * * @param \ReflectionParameter $parameter * @param array $parameters * @param object $skippableValue * @return mixed */ protected function transformDependency(ReflectionParameter $parameter, $parameters, $skippableValue) { // オブジェクトが必要なクラス名を取得 $className = Reflector::getParameterClassName($parameter); // If the parameter has a type-hinted class, we will check to see if it is already in // the list of parameters. If it is we will just skip it as it is probably a model // binding and we do not want to mess with those; otherwise, we resolve it here. if ($className && ! $this->alreadyInParameters($className, $parameters)) { // 中略... // Service Containerからクラス名をキーにオブジェクトを取得 return $this->container->make($className); } // 中略... } |
思いのほかシンプルに動いていそうです。型ヒントで欲しいオブジェクトの型を指定していたことで、Service Containerからクラス名をもとにオブジェクトを取り出すことができます。
リクエストオブジェクトはService Containerに詰め込まれていることから、問題なく取り出されます。
Closure呼び出し
流れが見えてきたので、呼び出し元をもう一度見てみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | public function resolveMethodDependencies(array $parameters, ReflectionFunctionAbstract $reflector) { // 中略 // Closureが受け取る引数を1つ1つ走査 // keyはインデックス // parameterは引数そのものを表すReflectionParameterオブジェクトとなる foreach ($reflector->getParameters() as $key => $parameter) { // 引数の情報からオブジェクトを生成 $instance = $this->transformDependency($parameter, $parameters, $skippableValue); // 中略... // パスから組み立てられる引数を後ろに配置するための処理 // 基本的には引数を表す配列にオブジェクトを詰め込んでいると理解してOK $this->spliceIntoParameters($parameters, $key, $instance); } return $parameters; } |
難しそうな処理が並んでいましたが、流れを整理してみると理解できそうです。簡単にまとめておきましょう。
- Reflectionの仕組みを利用して、Closureの引数情報を読み出す
- 引数を1つ1つループで走査し、型ヒント情報からService Containerを介してオブジェクトを生成
- 得られたオブジェクトを引数リストを表す配列へ詰め込んで返却
更に戻って、Closureを呼び出しているところへと移ります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | /** * Dispatch a request to a given callable. * * @param \Illuminate\Routing\Route $route * @param callable $callable * @return mixed */ public function dispatch(Route $route, $callable) { // ...は配列を展開して個別に関数の引数として渡す return $callable(...array_values($this->resolveParameters($route, $callable))); } /** * Resolve the parameters for the callable. * * @param \Illuminate\Routing\Route $route * @param callable $callable * @return array */ protected function resolveParameters(Route $route, $callable) { return $this->resolveMethodDependencies($route->parametersWithoutNulls(), new ReflectionFunction($callable)); } |
得られたオブジェクトを引数にClosureを呼び出しています。
ということで非常に長くなりましたが、パスと対応する処理を呼び出すまでの流れをようやく掴めました。
Router::runRoute()
ここまでの処理を経ることで、文字列 Hello Laravel from helloがレスポンスとして得られました。
このままではHTTPレスポンスオブジェクトとして返せないので、よしなに変換している処理を見ていきたいです。
ということで、レスポンスを整形している処理がありそうな呼び出し元へと戻りましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | // Illuminate/Routing/Router.php /** * Return the response for the given route. * * @param \Illuminate\Http\Request $request * @param \Illuminate\Routing\Route $route * @return \Symfony\Component\HttpFoundation\Response */ protected function runRoute(Request $request, Route $route) { // 中略... return $this->prepareResponse($request, $this->runRouteWithinStack($route, $request) ); } |
Router::prepareResponse()でどうやってHTTPレスポンスへと変換されているのか、整理していきます。
Router::prepareResponse()
まずはメソッド定義から全体像を見ておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | /** * Create a response instance from the given value. * * @param \Symfony\Component\HttpFoundation\Request $request * @param mixed $response * @return \Symfony\Component\HttpFoundation\Response */ public function prepareResponse($request, $response) { return static::toResponse($request, $response); } /** * Static version of prepareResponse. * * @param \Symfony\Component\HttpFoundation\Request $request * @param mixed $response * @return \Symfony\Component\HttpFoundation\Response */ public static function toResponse($request, $response) { // 中略... if ($response instanceof PsrResponseInterface) { $response = (new HttpFoundationFactory)->createResponse($response); // 中略... // 文字列のレスポンスはこの分岐を通る } elseif (! $response instanceof SymfonyResponse) { $response = new Response($response, 200, ['Content-Type' => 'text/html']); } // 中略... // Response::prepare()はHTTPレスポンスのヘッダを整形 // 単に文字列を返すだけであれば関わりは薄いので割愛 return $response->prepare($request); } |
JSONやレスポンスっぽいオブジェクトなど、さまざまなオブジェクトをもとにレスポンスが組み立てられるよう、たくさんの分岐が書かれています。
今回のレスポンスは単なる文字列なので、最後の分岐を通ります。
文字列をもとに、Symfonyが提供するResponseクラスを拡張した、 Illuminate\Http\Responseオブジェクトを生成しています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | // Illuminate/Http/Response.php class Response extends SymfonyResponse { /** * Create a new HTTP response. * * @param mixed $content * @param int $status * @param array $headers * @return void * * @throws \InvalidArgumentException */ public function __construct($content = '', $status = 200, array $headers = []) { $this->headers = new ResponseHeaderBag($headers); // 今回の場合、contentに文字列・statusCodeに200(正常)が設定される $this->setContent($content); $this->setStatusCode($status); $this->setProtocolVersion('1.0'); } // 中略... } |
Response::send()
あとは呼び出し元にレスポンスオブジェクトを返すだけなので、エントリーポイントまで戻ります。
1 2 3 4 | // public/index.php $response = $kernel->handle( $request = Request::capture() )->send(); |
最後に Response::send()を呼び出して終わりのようです。
何をしているのか見ていきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | //symfony/http-foundation/Response.php /** * Sends HTTP headers and content. * * @return $this */ public function send(): static { $this->sendHeaders(); $this->sendContent(); // 中略... return $this; } /** * Sends content for the current web response. * * @return $this */ public function sendContent(): static { // $this->contentの中身は、文字列「Hello Laravel from hello」 echo $this->content; return $this; } |
最終的な仕組みはおどろくほどシンプルでした。
PHP標準のecho命令を呼び出すことで、WebサーバへHTTPレスポンスを出力しています。
あとはWebサーバが受け取ったレスポンスをよしなに処理していけば、ブラウザへ文字列が表示され、無事LaravelのHello Worldが達成されます。
振り返り
Hello Worldのように単に画面に文字列を表示させるだけの処理でしたが、とてつもなく長い道のりでした。
歩んできた道を忘れないよう、箇条書きで流れをまとめておきましょう。
- public/index.phpがエントリーポイント
- autoloaderでクラスを読み出せるようにしておく
- オブジェクトを用意・提供するService Containerを初期化
- あわせて、どういうオブジェクトをつくるか規定したService Providerと、Service Containerを連携させながらLaravelが動作するのに必要なオブジェクトを用意
- アプリケーションの制御を担うKernelオブジェクトをService Containerを介して生成
- Kernelオブジェクトのhandleメソッドを呼び出す
- routes/web.phpに書いたHello World処理をもとに、パスと実行する処理を表すRouteオブジェクトを作成
- リクエストのパスと合致するRouteオブジェクトを探し、対応する処理が呼ばれる
- Router・Routeオブジェクトを介してつくられたレスポンスをPHPのecho命令で出力することで、Hello Worldに相当する文字列が画面に表示される
これまでたどってきた処理、とくにService Container・Service ProviderはLaravelでアプリケーションをつくる上でとても重要です。
普段あまり触る機会が多くなくても、どういう仕組みで動いているのか、ざっくりとでも頭に入れておきましょう。
以降では、ちょっとした補足を残しておきます。
補足: artisan serveコマンドはいかにして動作しているのか
これまでは、 public/index.phpをエントリーポイントとした処理を見てきました。
しかし、開発するときには php artisan serveコマンドで開発サーバを動かす機会も多いはずです。このコマンドはどのように動いているのか、ものすごくざっくりとですが整理しておきます。
まずは全体像を描くために、やっていることを簡単に書き出しておきます。
- artisan serveコマンドによりPHPをビルトインサーバモードで起動
- router scriptとしてservrer.phpを指定
- server.phpにより public/index.phpが読み込まれる
- ※ cwdはProcessクラスにてpublic以下が指定される
- あとはnginxなどと同じような流れでリクエストを処理
エントリーポイントは、 .env`などが置かれているディレクトリにある`artisanファイルです。実体はPHPファイルなので、PHPスクリプトとして実行されます。
中身のソースコードも馴染みがあるはずです。中を見ていきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 | // artisan require __DIR__.'/vendor/autoload.php'; // Service Containerを用意 $app = require_once __DIR__.'/bootstrap/app.php'; // Consoleアプリケーション用のKernelオブジェクトを生成 $kernel = $app->make(Illuminate\Contracts\Console\Kernel::class); $status = $kernel->handle( $input = new Symfony\Component\Console\Input\ArgvInput, new Symfony\Component\Console\Output\ConsoleOutput ); |
Service ContainerやService Providerで準備を整え、Kernelで処理を実行。といったように public/index.phpで見たものと似通っています。
ここからの処理を詳細に見ていくと補足に収まり切らなくなってしまうので、重要な処理まで移動します。
Console KernelはService Providerなどを介して、実行する処理を表現するCommandオブジェクトを読み出します。
そして、コマンドライン引数(今回はserve)と対応するオブジェクトを実行するべき処理として呼び出します。
一気にまとめてしまうと、 ServeCommandが今回実行する対象となります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | // Illuminate/Foundation/Console/ServeCommand.php class ServeCommand extends Command { /** * The console command name. * * @var string */ protected $name = 'serve'; /** * The console command description. * * @var string */ protected $description = 'Serve the application on the PHP development server'; } |
コマンド名を表すプロパティを見ても、コマンドライン引数 serveと対応していることが分かります。
ServeCommandオブジェクトもたくさんの処理を担っているのですが、処理の流れに関わるところだけ見ておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | /** * Get the full server command. * * @return array */ protected function serverCommand() { $server = file_exists(base_path('server.php')) ? base_path('server.php') : __DIR__.'/../resources/server.php'; return [ (new PhpExecutableFinder)->find(false), '-S', $this->host().':'.$this->port(), $server, ]; } |
難しそうな処理が並んでいますが、やっていることを抜き出すと、PHPを開発サーバとして起動しています。
そして、パスに応じてリクエストを振り分ける処理として、 server.phpなるファイルを指定しています。
このファイルに artisan serveコマンドの正体が詰まっているので、中身を読み解きます。
1 2 3 4 5 6 7 8 9 | // Illuminate/Foundation/resources/server.php; // PHPを開発サーバとして起動するときに、publicディレクトリ以下を指定している $publicPath = getcwd(); // 中略... // public/index.phpが読み込まれる require_once $publicPath.'/index.php'; |
今まで見てきた