タグ別アーカイブ: PHP

CodeIgniter 4 RC1 インプレッション

Laravel 6 LTSの正式版が2019年9月3日にリリースされましたが、その数日前にCodeIgniter 4もついにRC1となりました。beta1が今年の3月でしたので最初のベータ版からおおよそ6カ月でのRCリリースとなりました。(Larabel 6に関しては記事を書く方が大勢居ると思うので……)まだ本格的なアプリを作っていない状態ではありますがCodeIgniter 4 RC1のパッと見た感じを記事にしたいと思います。個人的にトピックな点に触れていくので細かな違いはドキュメントを参照してみてください。

CodeIgniter公式
https://codeigniter.com/

Composerへの本格対応や名前空間への対応

CodeIgniter 3でもComposerで導入されたライブラリや独自定義のクラスをComposerのオートロードで読み込んだり、名前空間の定義されたクラスをアプリ内に含めたりnewしたりする事は出来ていたのですが、CodeIgniter自体をComposerで導入したり、CodeIgniter自体や作っていくコントローラやモデルなどで名前空間を使っていくようになりました。

なおComposerでの導入は必須ではなく、これまで通り圧縮アーカイブでダウンロードして配置して動かす事も出来ます。この辺りの選択肢を残しておくのはCodeIgniterらしくていいですね。また、Composerで導入する場合についても –no-devオプションを付けた場合(= PHPUnitを入れない場合)は数パッケージしか依存関係が有りません。一桁です。少なければ良いという訳ではないですが、フレームワークの全ての機能がそれぞれパッケージのようなSymfonyやLaravelに慣れていると方向性の違いを感じますね。

#導入
composer create-project codeigniter4/appstarter <任意のプロジェクト名> -s rc
# 内臓Webサーバでの実行
cd <今作られた任意のプロジェクト名のディレクトリ>
php spark serve
# →Webブラウザで http://localhost:8080 にアクセスすると仮のTOPページが見られる

JSON/XML形式でのレスポンス返却機能

ビュー(フロントエンド側)とのやりとりをJSONを返すAPIでやり取りする事が多くなった昨今ですが、CodeIgniter 4でもJSON/XML形式でのレスポンス返却が簡単になりました。例としてコントローラ内で

$data = [
    'status' => 'ok',
    'message' => 'json responsed'
]; 
 $this->respond($data, 200); 

と書いてやれば $data をJSONフォーマット化したレスポンスをHTTP 200で返してくれます。渡すのがarrayで良いってのはCodeIgniterっぽいですね。

respondはコンテンツネゴシエーション機能が文脈によってJSONではなくXMLを返したりします(WebブラウザでアクセスするとXML形式で表示されます)。この辺りは常にJSONを返したりなど設定変更可能です。また、他の形式での返却も追加できるようです。
https://codeigniter4.github.io/userguide/outgoing/api_responses.html

ORM的機能の追加

使う場面使わない場面有るとは思いますが、簡易?ORMが追加されました(ドキュメント上ではORMとはよばれずModel、Entityと記載)。もちろんほぼこれまで通りの直書きSQL+変数の自動エスケープ有りバインディングであったり扱いやすいクエリビルダも利用可能です。

まだ触ってはいないのですが、ドキュメントを読む限りテーブル名やプライマリキー名は手動指定できるタイプ、シンプルなCRUD機能を提供、論理削除対応、バリデーション対応、変更できないプロパティの指定に対応、JSON←→Arrayの自動変換などある程度の機能が揃っているようです。でもテーブル間のJOINやそれに関連する遅延ロード・Eagerロードは見当たらない? どの程度まで使い込めるのかは触っていないので正直まだ分からないのです。

基本は変わらないコントローラ

ルーティング方法がシンプルだからCodeIgniterが好きと言う人は結構いるんじゃないでしょうか(想像)。 クラス名やメソッド名がそのままルーティングになったりディレクトリ階層でパスを分けたりといったあの感覚はCodeIgniter 4でもそのまま利用できます。

Controllerクラスを継承する必要が有ったり、渡された値はInputクラスではなくIncomingRequestから取得するようになっていたりなど差は有るのでその辺は新しい作法にのっとっていく形になります。あとはアプリケーションのエラーを返す際にshow_error関数を呼ぶのではなくコントローラ内で例外をスローするようになっていたりするのも最近のフレームワークっぽいですね。

あとは使いたい人だけ使う形で良いと思いますが、Laravelにも有るようなReutfulなルーティングをまとめて用意する機能が追加されていたりします。APIを数作っていく場合は楽になるかもしれませんね。

神クラスCi_controllerからDI風味へ

CodeIgniter 3まではコントローラ(というかCI_controller)がサービスロケータとして機能しており、更にそれがあらゆる場所から利用できていましたがこれは無くなりました。代わりに Service という仕組みにより newされたインスタンスを取得するようになります。

基本的にはコントローラ内で必要なインスタンスをServiceとして取得、あとはコンストラクタインジェクションやメソッドインジェクションでという方向性のようです。Symfony 4.xほど強力なDIの仕組みではない(Symfony 4.xのDIは本当に強力)ですが、CodeIgniter 3の CI_loaderっぽさも残っていてシンプルなので移行はしやすそうですね。
https://codeigniter4.github.io/userguide/concepts/services.html

/Config/Services.php にクラスの生成を定義。これがサービスプロバイダ的な感じですね。

上記で生成される仮で作ったライブラリです。

コントローラから利用します。

.envでの設定に対応

.envファイルで設定値を上書きするような事が可能になります。他のフレームワークで見かける様な物と同様に環境ごとに変更したい設定が有る場合はこれで変更が可能です。

PSR-3準拠のロギング

ログを残す際のレベルがPSR-3に準拠するロガーで見かける様な物(RFC 5424)になりました。引き続きこれまで通りのlog_message関数が利用可能ですが内部的にはPSR-3準拠で作られたloggerサービスの log() を呼び出しています。DEBUGとERRORの間のレベルが欲しいと思う事が多かったので地味に助かるポイントです。他のPSR-3を実装するロガーへの入れ替えも可能なようです。

所感

CodeIgniter 3との細かい違いはそれなりに有ります。基本的にCodeIgniter 3のコントローラやモデルのコードはそのままでは動作しません。ただ、私がCodeIgniterの方向性だと(個人的に勝手に)思っている「薄く必要最低限で過剰に何かせずに分かりやすい感じ」はそのまま引き継がれているんじゃないかなという印象です。CodeIgniter 3のその部分が好きだったけど流石にもう設計の古さを感じるなという部分(名前空間非対応で有ったり)がアップデートされているので、悪くはない選択肢の一つになれればいいなぁという感想です。


「選定した技術が1年で死んだ話」の1年後

1年半前に以下のような記事を書きました。その記事が前提となり、その続きになります。

対応の方向性

2018年末ごろから Symfony 4.2 への移行を始めました。Symfony 4 についての日本語情報はかなり少なかったので、数少ない日本語情報に感謝をささげながら、基本は Symfony 公式のドキュメントを Google翻訳にかけて読みながら対応しました。

※ 得られた知見を本ブログ内別記事にまとめています。

Silex 1.x → Symfony 4.2 への移植の実際

現状の2代目システムの実装としては Silex 1.x での実装となり、依存性注入の仕組みは Pimple というアレイアクセスベースのシンプルなサービスロケータ、クラス構成の主要な部分としては、コントローラ、サービス、リポジトリのインタフェース、リポジトリ、DoctrineDBALで読みだしたレコードを保持したりバリデーションが実装されていたりするレコードオブジェクトという構成になっていました。

コントローラとビュー

まずはコントローラの移植になりますが、基本的にはこの部分が実コードでは一番重いものになりました。Silexのルーティングから Symfony のアノテーションを使った物に置き換えていく作業は主に以下の内容になりました。

  • SilexのクロージャベースのルーティングをSymfonyのアノテーションベースのルーティングに書き換える作業を進めます。どちらか一方でしか出来ない機能という物がなく、淡々と対応すれば完了しました。ただし物量が多い。
  • Requestオブジェクトなど要素要素の機能はもともとSymfonyコンポーネントを使っていたSilexなのもあり、そのまま使い続ける事が出来る。
  • リダイレクトなどは関数名が変わってくるので調整する。
  • ビューはTwigがそのまま使えるのでセッションに関する扱いだけ調整すればそのまま動作する。
  • Pimpleを使っていたDIは全てコンストラクタインジェクションに変更。あとはSymfonyが勝手にサービスを注入してくれる。

ルーティングは書き換えになりますがコントローラ内のアクション処理としては9割そのままコピペで動いた印象です。残りの1割を書き換えていきました。

サービス

ここでいうサービスは所謂ビジネスロジックです。サービスクラスは一部Pimpleのサービスロケータを引き回している部分が有ったので全てコンストラクタインジェクションか、コントローラから呼ばれる際のメソッドインジェクションに変更しました。ログ出力に関しても同様に Psr\Log\LoggerInterface を注入するように変更。それ以外はSilex独自の機能への依存がほとんどなく、ほぼそのまま動作しました。

リポジトリとレコードオブジェクト

リポジトリの実装はDoctrineDBALの存在にがっつり依存していましたが、これはSymfonyでも同様に利用できるので問題になりませんでした。ほとんどの処理がそのまま動作しました。

テスト

PHPUnitで実装されたテストは全体の2~3割程度に調整が必要になりました。この背景として元々使っていた phpunit/dbunit の開発終了が有ります。
https://github.com/sebastianbergmann/dbunit

データベース周りのテストを行う際にレコードの取得結果を比較したり、YAMLファイルで定義したデータをDBに流し込んだりリセットしたりなどの機能を提供しているライブラリなのですが、これが開発終了し新しいPHPUnitに対応していかなくなる事態になりました。

色々方法は考えたのですが、phpunit/dbunit の提供する機能のうち、実際に利用してたものだけについて互換実装を作り込んで使う事にしました。YAMLファイルを読み込んでDBに書き込む機能、欠けた部分のある連想配列を欠けていない部分のみで比較する機能などを関数のインタフェースに互換性を持たせながら実装して、これは1ファイル1クラスのシンプルな互換機能になりました。もちろん PHPUnit 8系で問題なく動作する物になっています。

結果

期間としては大体3か月程度でSymfony 4.2 への移植が完了しました。これは想定よりもだいぶ短い期間でした。併せて PHP 7.1 から 7.2 への移行を行ったり様々な追加機能を載せたりしていますが、現状問題なく運用し続けています。上手く行った要因としては以下が有ったのかと思います。

  • Silex 自体の開発が終了したと言っても Symfony は健在なので、置き換えが必要なクラス、機能が最小限で済んだ。結果論ではあるがSilex採用時の「Symfonyコンポーネントを使ったフレームワークにしよう」という選択に助けられた。
  • もともとサービスクラス、リポジトリ、レコードオブジェクトがほぼSilexに依存しておらず、依存関係も依存性注入を使った作りになっていたので移植コストが低かった。再設計時の設計が(ベストかどうかはともかく)悪くなかった。
  • 初代システム(1ページ1PHPファイル)とは違って2代目システムはテストコードが有ったので、動作確認のコストが抑えられた。テストが書かれていなかった部分やテストは書かれているもののカバーしきれていなかった動作、その他もろもろでバグは出たものの、それでもテストが無い状態よりははるかに楽になった実感が有る。

結論

  • フレームワークの機能を便利に使いつつも 、それに依存しすぎない疎結合な設計になっているとフレームワークが開発終了に見舞われてもコードの大部分をそのまま動かす事が出来る。それまで「疎結合大事って言ってもライブラリ、ユーティリティ的なクラス以外はあんまり再利用したりしなくない? テストが書きやすくなるのは間違いないけど」と思う部分も有ったが、テストが書きやすいだけではないフレームワークに対する疎結合の重要性を体感した。
  • さすがにフレームワークが変わるレベルだと動かなくなるテストコードも少なくないので「元と同じテストが全部通ればOK」とはならないものの、とはいえ有るのと無いのでは全く違う。テストコード大事。

マイクロフレームワークっぽく使う Symfony 4 事始め 6 ~本番環境公開編~

Symfony 4 入門。前回の記事は以下

dev モードから prod モードに切り替える

第5回のこれまではずっと dev モードで開発してきました。dev モードでは例えば以下のような機能が提供されています。

  • Webページ下部に表示されるプロファイラ
  • 発行されたSQL全てがログに出力される(プロファイラ内でも確認できます)

前者は中身が筒抜けになり、後者は動作が遅くなりログサイズが爆発する原因になるのでどちらも本番環境として公開するには無効化しておきますよね。その場合は .env ファイル内での APP_ENV=dev の定義を APP_ENV=prod に変更する事で本番環境としてのモードに切り替える事が出来ます。もちろん .env.local で上書きする方法でも問題ありません。prod モードでは以下のような挙動の違いが有ります。

  • Webページ上にプロファイラが表示されない。
  • 発行されたSQLのログがログファイルに出力されない。
  • 設定ファイルの内 config/packages/dev 内の物がが読み込まれていた物は config/packages/prod 内の物が読み込まれるようになる。
  • ログのファイル名の dev の部分が prod になる。
  • キャッシュが自動的に更新されない。
  • bin\console server:run が使えない。

このうち「キャッシュが自動的に更新されない」件に関しては注意が必要です。プログラムのコードやビューテンプレートのコードを編集しても反映されなくなる場合が有ります。prod モードで運用している場合、改修のデプロイ後はキャッシュをクリアするようにしましょう。これはSymfonyのコマンドから実行する事が出来ます。

実行するには
php bin\console cache:clear
を実行します。

これでキャッシュが削除・更新されました。CIツールなどでデプロイを自動化しているような場合はこの操作を組み込んでおくといいんじゃないかと思います。

また、 bin\console server:run が使えなくなる件については確かに開発用の機能なのでそれも仕方ないかなという感じでは有りますが、ドキュメントルートになる public ディレクトリ内でPHPのビルトインサーバーを自分で起動してやれば dev モード時と同じようにビルトインサーバーで動作確認が可能です。