Slide 1
Slide 1 text
PSR-15 はあなたのための
ものではない？
2024/12/22
phpcon2024
やまゆ
Slide 2
Slide 2 text
説明文
PHP Standards Recommendations 、通称 PSR と呼ばれる、 PHP エコシステムで
共通のインターフェースを宣言し、それに準じて実装することで再利用性・可搬性
を向上させる施策があります。
その中でも今回は PSR-15 に焦点を当てて、この PSR が 誰のために作られ、どう
やって使っていくことが求められているのか をインターフェースから解説していき
ます。
handle という 1 メソッドだけが宣言されたこのインターフェース、一体どう使え
ば良いのでしょうか？ PSR-7 に批准していない Laravel(Symfony) ユーザーはどう
これをとらえれば良いのでしょうか？
PSR-15 批准フレームワークを 自作 して得た PSR との向き合い方をご紹介しま
す。
Slide 3
Slide 3 text
やまゆ
札幌でのびのび暮らす
ただのにじさんじ🌈オタクです
Slide 4
Slide 4 text
登壇活動
Slide 5
Slide 5 text
本日のお題
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
PHP-FIG?
The PHP Framework Interoperability Group(The PHP FIG) はプロジェクト
と人々が協力して PHP エコシステムと良い標準を推進していくことを目的と
しています。
PSRs, PERs, ARs を作成するために、実際の世界での経験とそれらの研究及
び実験の元、標準を開発し公表します。
Mission and Structure - PHP-FIG
Slide 8
Slide 8 text
PHP-FIG?
主要なフレームワークやライブラリの中で、 PHP エコシステムのために共通
の標準規則を持とう、という非公式のグループ。
この標準にのっとった実装を提供することで、フレームワークやライブラリ
間の相互運用性(Interoperability)を向上させることが目的。
現段階でコーディングガイドラインや各種インターフェース定義が提供され
ています。
Slide 9
Slide 9 text
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
Slide 10
Slide 10 text
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 インターフェースと互換をとるも
のもあります。
Slide 11
Slide 11 text
PSRs?
PHP Standards Recommendations(PSRs) は、 PHP エコシステムの標準の規
則やインターフェース定義の一覧です。
今回はその中でも HTTP Interfaces である PSR-15 を題材とします。
Slide 12
Slide 12 text
https://speakerdeck.com/akaiinu/korekara
Slide 13
Slide 13 text
PHP の本来の役割
Slide 14
Slide 14 text
PHP の本来の役割
アプリ
HTTP Request
PHP DB
HTTP Response
Slide 15
Slide 15 text
PHP の本来の役割
アプリ
HTTP Request
PHP DB
HTTP Response
[1] HTTP リクエストを受け取って
Slide 16
Slide 16 text
PHP の本来の役割
アプリ
HTTP Request
PHP DB
HTTP Response
[1] HTTP リクエストを受け取って
[2] なんやかんや処理して
Slide 17
Slide 17 text
PHP の本来の役割
アプリ
HTTP Request
PHP DB
HTTP Response
[1] HTTP リクエストを受け取って
[2] なんやかんや処理して
[3] HTTP レスポンスを返す
Slide 18
Slide 18 text
抽象化！
Slide 19
Slide 19 text
PHP の本来の役割を抽象化
アプリ
PSR-7
ServerRequestInterface
PSR-15
RequestHandlerInterface
PSR-7
ResponseInterface
Slide 20
Slide 20 text
PSR-15: RequestHandlerInterface
HTTP リクエストを受け取り、 HTTP レスポンスを返すメソッドを定義
Slide 21
Slide 21 text
PSR-15: MiddlewareInterface
RequestHandlerInterface の前後に処理を差し込めるインターフェース。
Slide 22
Slide 22 text
🤔
Slide 23
Slide 23 text
例えば Laravel の MVC コントローラ
Slide 24
Slide 24 text
例えば Laravel のミドルウェア
Slide 25
Slide 25 text
Laravel のライフサイクル
1. Application(extends ContainerInterface) を生成
2. Application を初期化
3. スーパーグローバル変数から Request クラスを生成
4. ルーティングを解決
5. Middleware の配列を順番にコール
a. $next の前の部分をコール
b. 最後の Middleware として Controller を解決してコール
c. $next の後の部分をコール
6. レスポンスを出力
Slide 26
Slide 26 text
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 拡張コーディング規約などは準拠しています。
Slide 27
Slide 27 text
そもそも HTTP は隠ぺいされるべき！
Slide 28
Slide 28 text
そもそも HTTP は隠ぺいされるべき！
ドメインロジックに HTTP に依存するものはなくなるべき
アプリ
HTTP
Action
DB
ドメイン
ロジック
Log
AWS
Slide 29
Slide 29 text
そもそも HTTP は隠ぺいされるべき！
ドメインロジックに HTTP に依存するものはなくなるべき
アプリ
HTTP
Action
DB
ドメイン
ロジック
PSR の領分はココ
Log
AWS
Slide 30
Slide 30 text
PSR-15 は
あなたのためのもの
ではない！
ことが多い。
Slide 31
Slide 31 text
PSR-15 は
あなたのドメインロジック
を守る「防壁」を定義する
Slide 32
Slide 32 text
オニオンアーキテクチャの外側は「防壁」
HTTP
Action
DB
ドメイン
ロジック
Log
AWS
ここが防壁！
- フレームワーク
- ライブラリ
に身を委ねる部分
ドメインロジックは
HTTP や DB の
プロトコルを意識
することなく開発
をすることが出来る
ことがベスト！
Slide 33
Slide 33 text
じゃあ誰のため？
Slide 34
Slide 34 text
FW/Library のため！
Slide 35
Slide 35 text
PSR-15 準拠フレームワーク
https://packagist.org/providers/psr/http-server-handler-implementati
on
あれ、意外と...ない？
PSR-15 が Accept されたのは 2018 年。 6 年経ってますが新しいフレーム
ワークで大きくなったものはほぼなく、古いフレームワークは後方互換性の
ためインターフェースが違います。
Slide 36
Slide 36 text
じゃあ
作るか。
Slide 37
Slide 37 text
No content
Slide 38
Slide 38 text
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
Slide 39
Slide 39 text
大体みんなこういう構成にいきついている様子
Slide 40
Slide 40 text
Controller 相当の部分は HTTP より下
Slide 41
Slide 41 text
HTTP の処理部分
Slide 42
Slide 42 text
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)
Slide 43
Slide 43 text
RoadRunner や FrankenPHP にも対応可能
- PSR-17 の代わりに PSR-7 ServerRequest を生成してくれる
- $response = $handler->handle($request); は同じコードベース
- クライアントへの返却は RoadRunner/FrankenPHP 側に移譲
Slide 44
Slide 44 text
Laravel/Symfony には Bridge が存在
- Laravel/Symfony でも PSR-7, 15 っぽい書き方が可能
Slide 45
Slide 45 text
まとめ: 防壁を作る人向けの PSR-15
- PHP の本質的な処理は HTTP メッセージの処理
- -> PSR-7 で抽象化
- HTTP 処理を実行するインターフェースが PSR-15
- ドメインロジックとは切り離されて考えるべき
- フレームワークやライブラリで相互運用性を高めるための定義
- Laravel/Symfony では Bridge 経由で利用可能
- アーキテクトをする人はこのインターフェースを考慮してみると良い