Page 1
ふつうのpixivのつくりかた
An introduction to building pixiv for ordinary PHPers
pixiv Inc.
USAMI Kenta
2023-07-26 PHP の今を語る！4社合同勉強会
Page 15
(こっそり使ってる部分もありますが大筋は追えるはず)
Page 16
PHP詳しくない人でも雰囲気に従って書けばセキュリティの問題は起こさないように
Page 19
10年前のコードのイメージ
include_onceいっぱい
エラーハンドリング(してないページもあった)
<?php // www.pixiv.net/htdocs/hoge.php require_once __DIR__ . '/../inc/bootstrap.php';include_once INC_PATH . '/Hoge/Fuga.php';include_once INC_PATH . '/Hoge/Piyo.class.php';try {display()} catch (Exception $e) {error::exception_error($e);}
この下にもいっぱい
ファイルローカルな
function display() {// ...
グローバル関数
Page 20
2015年のコードのイメージ
<?php // www.pixiv.net/htdocs/hoge.php require_once __DIR__ . '/../inc/bootstrap.php';
include_once一個だけ
AppRunner::execute(new Www_HogeController);
このクラスは自動ロードされる
Page 21
2018年のコードのイメージ
htdocs/hoge.phpは消滅
URLとファイルは切り離され
マップの一要素に
全URLが1ファイルに
final class Controller_WwwRoutes {public static function getRoutes() {$route_map = ['/' => ['action' => function () {Www_IndexController::main();},],'/hoge.php' => ['action' => function () {Www_HogeController::main();},
Page 23
2023年こうなりたい
... ですっきり
<?php // WwwRoutes.php public static function getRoutes() {return ['/' => Www_View_IndexController::main(...),'/hoge' => Www_View_HogeController::main(...),'/.well-known/change-password' => fn() =>Util_Http::redirect_and_exit(ReverseRoute::fullAccountsPasswordChange([])),],
Page 24
コントローラをdispatchする処理
<?php
whoops
final class PCAppRunner {public static function execute(Closure $action) {try {Controller_Util::turnOnWhoops();Controller_Util::redirectToHttps();
パソコン版
$action();} catch (\Throwable $exception) {PCAppRunner::setHttpStatus(500);Controller_Util::displayWhoops($exception);
Page 28
クエリパラメータの問題
$id = $_GET['user_id'];if (is_numeric($id)) User_Common::getById($id);else error("不正な入力です");
- こういうコードを書いてはいけない
- クエリパラメータに数字ではない値が入ってくる可能性
- 入力が空、入力が任意の文字列、入力が不正な数字列、入力が配列
filter_input() をかけると安全にはなるが、それでも面倒
Page 29
ParamHelper
$id = ParamHelper::get('id')->asPositiveInt();$user = User_Common::getById($id);
- 外部入力から値を取り出すヘルパー
- クエリパラメータ・フォーム・URL・JSONなどに対応・拡張可能
- 未入力や不正な入力があると例外を投げる
- キャッチしてエラー画面を描画する
Page 30
ParamHelper
$mode = ParamHelper::get('mode')->asStringInArray['hoge', 'fuga']);
- ?mode=hoge または ?mode=fuga のみを期待するようなパターン
- 不正な形式や ?mode=piyo のような期待しない入力で例外を投げる
- PHPStan拡張で 'hoge'|'fuga' という型をつけている
- 型安全と実行時安全の両立！ (PHPカンファレンス沖縄で話します)
Page 31
テンプレートとURL生成の問題
<a href="{$smarty.const.SYSTEM_URL_WWW|escape}member_illust.php?id={$user.id|escape}">{$user.name|escape}</a>
- こういうコードを書くと事故が入り込みやすい
- 純粋にtypoの危険性
- idなどのパラメータに不正な値を入れるリスク
Page 32
<a href="{reverse_route page='fullWwwMemberProfile' id=$user.id}">{$user.name|escape}</a>
- あるページに名前をつけて、reverse_route関数に page 引数で渡す
- 生成結果は変更前と同じ
- ルーティングの逆関数にあたるので、一部のフレームワークは
ReverseRoutingやURLヘルパーなどの名前でサポートしてる
Page 33
/*** @route\example https://www.pixiv.net/member.php?id=12345 {id: 12345}* @route\example https://www.pixiv.net/member.php?id=12345&utm_source=xxxxx{id: 12345, utm_source: "xxxxx"}*/public static function fullWwwMemberProfile(array $params){Util_Assert::num($params['id']);
return ReverseRoute::buildUrl(SYSTEM_URL_WWW, '/member.php', ['id'],$params);}
Page 34
#[RouteExample('https://www.pixiv.net/member.php?id=12345', ['id'=> 12345])#[RouteExample('https://www.pixiv.net/member.php?id=12345&utm_source=xxxxx,['id' => 12345, 'utm_source' => 'xxxxx'])public static function fullWwwMemberProfile(array $params){Util_Assert::num($params['id']);
return ReverseRoute::buildUrl(SYSTEM_URL_WWW, '/member.php', ['id'],$params);}
Page 35
blogに書きました
https://devpixiv.hatenablog.com/entry/2016/10/25/093000
Page 36
PDOの問題
でもPDOで複雑なクエリを書こうとすると文字列結合が避けられない…
- PDOで書きにくいクエリの代表例: id IN (1, 2, 3)
- もう ? を並べてインデックスをインクリメントしながらbindValueはやだ…
- PDOのクエリのplaceholderに ? を書くか :hoge で書くか問題
- 型チェックできるように書くのもちょっとめんどう
- だからテンプレートエンジンを作ろう → PxvSql
Page 38
PxvSql
- 文字列結合を一切やらなくてもクエリが書けるようになった
- 実行時に型検査をするのでnullなどの不穏な値は入り込まない
- エラーチェックのボイラープレートがｸﾞｯと減る SQLi(脆弱性)のリスクなし
- :hoge@int で整数の埋め込み、 :fuga_ids@int[] で複数の整数を展開
する %if や %for の記法で条件分岐や複数SETなども可能
Page 42
新機能のリリース時にどうする？
- A: 新機能が実装されたブランチをリリースするときマージする
- B: リリース前にあらかじめマージして、実行されないようにしておく
- よくある問題
- Aは機能の規模が大きいとビッグバンマージを引き起こし、
予期せぬ問題を引き起こすことがある (コンフリクト解決が大変)
- 理想としてはBで、一般ユーザー向けに実行されないとしても
鮮度のよいうちにマージしておきたい (リリース時の変更を最小限に)
Page 43
機能の有効化／無効化
if ($_SERVER['REMOTE_ADDR'] === OFFICE_IP) {hogehoge();}
- 新しい機能をサービスに実装して、社内でだけ有効化したいとする
- 無造作にこんなコードを書かれると後から意味不明になるそもそも社外と社
内での挙動が別物になるので嫌な予感しかしない
Page 44
フィーチャートグル
if (ABTest_DevToggle::isEnabledDevToggle('hogeFunc')) {hogehoge();}
- 専用のコンソール画面でボタンを押すことで有効化／無効化される
- 設定を一行足すだけで一般ユーザーに対してリリースできる
- リリース後に障害などが発生しないことが確認できたらifを消す
- 元はA/Bテストのための機構だった (一般ユーザーに対して確率で適用)
Page 46
何もない野原に秩序をつくる
- べんり機能を導入すると、部分的に生産性が体感で数倍になったりする
- 一からサービスを作るとしたら同じことを繰り返せるかは、悩む
- いまならLaravelを入れるかもしれないが、それは未来人だからできる発言
- サービスの価値はコードではなく、その結果のユーザー体験
- フレームワークがなかったとしても、
pixivが2007年からユーザーに価値を提供してきた結果は変らない
