PSR-15 はあなたのための ものではない？ - phpcon2024

PHP Standards Recommendations 、通称 PSR と呼ばれる、 PHP エコシステムで共通のインターフェースを宣言し、それに準じて実装することで再利用性・可搬性を向上させる施策があります。
その中でも今回は PSR-15 に焦点を当てて、この PSR が 誰のために作られ、どうやって使っていくことが求められているのか をインターフェースから解説していきます。
handle という 1 メソッドだけが宣言されたこのインターフェース、一体どう使えば良いのでしょうか？ PSR-7 に批准していない Laravel(Symfony) ユーザーはどうこれをとらえれば良いのでしょうか？
PSR-15 批准フレームワークを 自作 して得た PSR との向き合い方をご紹介します。

Transcript

1. PSR-15 はあなたのための ものではない？ 2024/12/22 phpcon2024 やまゆ
2. 説明文 PHP Standards Recommendations 、通称 PSR と呼ばれる、 PHP エコシステムで 共通のインターフェースを宣言し、それに準じて実装することで再利用性・可搬性 を向上させる施策があります。 その中でも今回は PSR-15 に焦点を当てて、この PSR が 誰のために作られ、どう やって使っていくことが求められているのか をインターフェースから解説していき ます。 handle という 1 メソッドだけが宣言されたこのインターフェース、一体どう使え ば良いのでしょうか？ PSR-7 に批准していない Laravel(Symfony) ユーザーはどう これをとらえれば良いのでしょうか？ PSR-15 批准フレームワークを 自作 して得た PSR との向き合い方をご紹介しま す。
3. やまゆ 札幌でのびのび暮らす ただのにじさんじ🌈オタクです
4. 登壇活動
5. 本日のお題
7. PHP-FIG? The PHP Framework Interoperability Group(The PHP FIG) はプロジェクト と人々が協力して PHP エコシステムと良い標準を推進していくことを目的と しています。 PSRs, PERs, ARs を作成するために、実際の世界での経験とそれらの研究及 び実験の元、標準を開発し公表します。 Mission and Structure - PHP-FIG
8. PHP-FIG? 主要なフレームワークやライブラリの中で、 PHP エコシステムのために共通 の標準規則を持とう、という非公式のグループ。 この標準にのっとった実装を提供することで、フレームワークやライブラリ 間の相互運用性(Interoperability)を向上させることが目的。 現段階でコーディングガイドラインや各種インターフェース定義が提供され ています。
9. PHP-FIG? 様々な PHP 製ライブラリ・フレームワークの著者がコミットしています。 AMPHP, AzuraCast, CakePHP, Composer, Concrete CMS, Contao Open Source CMS, Horde, Hyperf, IBM i Toolkit, Jackalope, Joomla, Laminas Project, Lithium, Magento, PEAR, Phalcon, Phing, phpBB, phpDocumentor, PHPixie, Pimcore, PPI Framework, PrestaShop, PyroCMS, ReactPHP, Revive Adserver, Sculpin, Slim, SilverStripe, Stash, SugarCRM, TYPO3, Flow and Neos, Wikibase and Semantic Media, Yii framework, Zikula
10. PHP-FIG? 以下のプロジェクトは “音楽性の違い[要出典]” によりこのグループを離れま した。 Aura and Solar, Assetic, Agavi, Doctrine, eZ Publish, Guzzle, Laravel, The League of Extraordinary Packages, Phergie, Propel, sabre/dav, Stormpath PHP SDK, Symfony, Drupal 中には Adapter や Bridge パターンで PSR インターフェースと互換をとるも のもあります。
11. PSRs? PHP Standards Recommendations(PSRs) は、 PHP エコシステムの標準の規 則やインターフェース定義の一覧です。 今回はその中でも HTTP Interfaces である PSR-15 を題材とします。
12. https://speakerdeck.com/akaiinu/korekara
13. PHP の本来の役割
14. PHP の本来の役割 アプリ HTTP Request PHP DB HTTP Response
15. PHP の本来の役割 アプリ HTTP Request PHP DB HTTP Response [1] HTTP リクエストを受け取って
16. PHP の本来の役割 アプリ HTTP Request PHP DB HTTP Response [1] HTTP リクエストを受け取って [2] なんやかんや処理して
17. PHP の本来の役割 アプリ HTTP Request PHP DB HTTP Response [1] HTTP リクエストを受け取って [2] なんやかんや処理して [3] HTTP レスポンスを返す
18. 抽象化！
19. PHP の本来の役割を抽象化 アプリ PSR-7 ServerRequestInterface PSR-15 RequestHandlerInterface PSR-7 ResponseInterface
20. PSR-15: RequestHandlerInterface HTTP リクエストを受け取り、 HTTP レスポンスを返すメソッドを定義
21. PSR-15: MiddlewareInterface RequestHandlerInterface の前後に処理を差し込めるインターフェース。
22. 🤔
23. 例えば Laravel の MVC コントローラ
24. 例えば Laravel のミドルウェア
25. Laravel のライフサイクル 1. Application(extends ContainerInterface) を生成 2. Application を初期化 3. スーパーグローバル変数から Request クラスを生成 4. ルーティングを解決 5. Middleware の配列を順番にコール a. $next の前の部分をコール b. 最後の Middleware として Controller を解決してコール c. $next の後の部分をコール 6. レスポンスを出力
26. Laravel/Symfony が PHP-FIG から離れた理由 https://groups.google.com/g/php-fig/c/XEjh7j2iuls/m/qrHdymmoAwAJ Symfony のミッションと PHP-FIG のミッションが乖離したため。 Symfony は後方互換性を非常に重要視したプロダクトであり、 PSR は後発。 後から定義されたインターフェースに今の実装を寄せることは難しいと判断 された様子。 大きな点として、 PSR-7 のオブジェクトは Immutable である必要がある が、 Symfony はそうなっていない。 ただ、 PSR-12 拡張コーディング規約などは準拠しています。
27. そもそも HTTP は隠ぺいされるべき！
28. そもそも HTTP は隠ぺいされるべき！ ドメインロジックに HTTP に依存するものはなくなるべき アプリ HTTP Action DB ドメイン ロジック Log AWS
29. そもそも HTTP は隠ぺいされるべき！ ドメインロジックに HTTP に依存するものはなくなるべき アプリ HTTP Action DB ドメイン ロジック PSR の領分はココ Log AWS
30. PSR-15 は あなたのためのもの ではない！ ことが多い。
31. PSR-15 は あなたのドメインロジック を守る「防壁」を定義する
32. オニオンアーキテクチャの外側は「防壁」 HTTP Action DB ドメイン ロジック Log AWS ここが防壁！ - フレームワーク - ライブラリ に身を委ねる部分 ドメインロジックは HTTP や DB の プロトコルを意識 することなく開発 をすることが出来る ことがベスト！
33. じゃあ誰のため？
34. FW/Library のため！
35. PSR-15 準拠フレームワーク https://packagist.org/providers/psr/http-server-handler-implementati on あれ、意外と...ない？ PSR-15 が Accept されたのは 2018 年。 6 年経ってますが新しいフレーム ワークで大きくなったものはほぼなく、古いフレームワークは後方互換性の ためインターフェースが違います。
36. じゃあ 作るか。
38. Shibare PHP Simple, Short, Smart Framework - All things are explicit, understandable. - No magic method. - No dynamic types. - All have static types(with https://phpstan.org/). - short is simple. - PHP Standards Recommendations compatible implementation components - Smart DI Container, it can bind and resolve anything - Smart Database Abstraction with PDO: TODO - Supports multiple server runtimes - IDL Support
39. 大体みんなこういう構成にいきついている様子
40. Controller 相当の部分は HTTP より下
41. HTTP の処理部分
42. PSR-15 的処理 1. Kernel の初期化(Container 等インスタンスの初期化) 2. PSR-17 で ServerRequest をインスタンス化 3. $kernel->handle($request); a. Routing を解決 b. Middleware を解決 c. LIFO で Middleware を process d. 最後に解決したルーティングのハンドラを handle 4. 戻ってきた Response を emit(echo)
43. RoadRunner や FrankenPHP にも対応可能 - PSR-17 の代わりに PSR-7 ServerRequest を生成してくれる - $response = $handler->handle($request); は同じコードベース - クライアントへの返却は RoadRunner/FrankenPHP 側に移譲
44. Laravel/Symfony には Bridge が存在 - Laravel/Symfony でも PSR-7, 15 っぽい書き方が可能
45. まとめ: 防壁を作る人向けの PSR-15 - PHP の本質的な処理は HTTP メッセージの処理 - -> PSR-7 で抽象化 - HTTP 処理を実行するインターフェースが PSR-15 - ドメインロジックとは切り離されて考えるべき - フレームワークやライブラリで相互運用性を高めるための定義 - Laravel/Symfony では Bridge 経由で利用可能 - アーキテクトをする人はこのインターフェースを考慮してみると良い