実装の薄さで言えばトップクラスの PHP マイクロフレームワーク Slim Framework の最新メジャーバージョン、 v4 のアルファ版がリリースされていました。
v4 の作成中ドキュメントは現在こちらで閲覧出来ます(リリース後は URL 変わりそう)。
リリースノートはこちらで、フィードバックはこちらで受け付けているようです。
※ Slim Framework 自体についての紹介は省略します。
v3 からどう変わった？
PSR 準拠を進めた
PSR-7: HTTP Message Interface
PHP のスタンダードなインターフェース(なお Symfony/Laravel 系列を除く)として存在する PSR 準拠をデザインの主軸に置いている Slim ですが、 v3 では PSR-7 である HTTP Message 部分を自前で実装して提供していました。
v4 からはその実装も slim/psr7 の方に移動していて、ユ－ザが任意の PSR-7 実装を選択して使えるようになっています。
現在は公式として Slim PSR-7, Nyholm PSR-7, Guzzle PSR-7, Zend Diactoros の四種類がサポートされています。インターフェースを実装することでその他の PSR-7 実装を利用することも可能です。
公式でサポートされている実装は, require するだけで自動的に存在するかどうかを判別してくれます。
PSR-11: Container Interface
PSR-11 Container は Pimple がデフォルトでインストールされていました。
Pimple もまたマイクロな DI コンテナとなっていて、本当に「手動で登録して」「手動で取得する」しか出来ないシンプルなものでした。コンストラクタに型を記述しておけば自動で依存関係を解決してインスタンス化出来る AutoWiring 機能を持っているのが一般的な DI コンテナです。
この Pimple も依存関係から外れて、 DI コンテナ実装を自由に選べるようになりました。
PSR-15: HTTP Handlers
最もメインで破壊的な変更として、 PSR-15 HTTP Handlers による HTTP ハンドリングを行う形式になったことが挙げられます。
PSR-15 を最速で実装して話題になったのは Zend Expressive ですが、それに追従する形となります。
これは PSR-7 の Request を受け取って、 Middleware を経由し、 Response を生成する、という一連の流れを定義したインターフェースです。
Slim\App メインクラスがこの RequestHandlerInterface を実装したものとなっています。
PSR-17: HTTP Factories
PSR-7 の Request や Response クラスをどう生成するのか定義した PSR-17 HTTP Factories も利用されています。
ルーティングの実装依存を弱めた
これまで通り nikic/fast-route を依存として明示されていて、これを利用したルーティングを実装していますが、インターフェ－スを経由してユーザが異なるルーティングライブラリを使うことも出来るようになりました。いよいよ何を実装しているのかわからないレベルです。
エラーハンドリングを実装しやすくした
v3 で任意のエラーハンドリングを行う際は、コンテナの errorHandler キ－に関数を登録する形で、 403/404/PHP Error は別のキ－に登録する必要があるなどかなり分かりづらい形式でしたが、今回から ErrorMiddleware が実装され、ミドルウェアを通してハンドリングを調整出来るようになりました。
また、例外が SlimException ではなく HttpException となり、各種ステ－タスコ－ドごとのクラスに分けられたので、型を見て処理を分けることができるようになりまし。
レスポンスの Emit をカスタマイズしやすくした
v3 では Slim\App クラス内でレスポンスを出力していましたが、任意の実装で出力出来るよう Slim\EventEmitter クラスに分割されました。
連想配列によるコンフィグをやめた
以前は謎の連想配列をコンフィグとして Slim\App クラスのコンストラクタに渡し挙動を変更していましたが、代わりにそれぞれの設定を複数の Middleware クラスのコンストラクタで明示的に指定するようになりました(エラ－を表示するかどうかなど)。
根本的に、 Slim は HTTP リクエストを受け取り、適切なコールバックルーチンを実行し、 HTTP レスポンスを返すだけの Dispatcher である
Slim のコアコンセプトとしてこのようなものが挙げられています。 PHP 利用者は HTTP プロトコルの処理を($_GET などを通して...)したいわけではなく、受け取ったリクエストを処理してレスポンスを生成したいだけです。
PHP 特有の HTTP プロトコル周りの難しい処理を Slim が全て行ってくれるので、 Slim の利用者は 実装したい処理だけ を実装することができます。
個人的にはかなり,かなり良くなったと思います。
v3 までの実装だと,「小規模な実装であれば使えそうだけど,スケールしづらいなあ...」と思っていましたが,ここまで抽象化が進んでいれば 大規模な所までスケールして いけるのではないかという期待があります。
DDD によるサンプル実装として l0gicgate/Slim-Skeleton が提供されています。これをみるとスケールも全然出来そうな可能性を感じます。
代わりに、 v3 との変更がかなり大きいため,バージョンアップはかなり厳しいのではないでしょうか。 v3 を使っている人はそのまま,これから新しくアプリケーションを構築する人は v4 を使っていくのが良いのではないでしょうか。これからの動向が楽しみですー。