１年間 Phalcon2 を使ってみた感想（2016~2017）

By: yunguyen666

PHP のフレームワークの中でも高速と言われている「Phalcon」の2系を1年ほど使ってみました。
いったいどんなものなのか？　CakePHP や Yii2 などと比べてどうなのか、という所感を述べてみます。

自分でいろいろ書き出してみて分かりましたので、結論から言いますと、
「日本で使うには向いていない」。ということです。

もし、英語がそれほど嫌いでなく、Composer や PHP7 などの新しい技術が出てきても、貪欲に学べる人なら大丈夫です。
でも、日本は英語アレルギーのエンジニアが多い（少なくとも私の周りは）ので、サポート体制という意味からしても、誰か一人に一極化しそうです。
リリースが済んだらすぐ人を切るような、日本の開発現場ではリスクが高いといえます。

第一印象は「テンションが低い」

PHPのエクステンションを設置するだけで使えるという手軽さ、とは言われていますが、格安レンタルサーバでは導入が難しいからか、今いち、日本では盛り上がりに欠けている、という印象です。

しかも、公式サイトはマニュアルの半分くらいまでしか日本語化が進んでいません。
ちょっと先に読み進めると、翻訳が止まっているといった具合。

多少、英語マニュアルに通じている方なら、優しい英語なので大体読み解けますが、英語アレルギーの方には厳しい状況です。
もちろん、大手出版社の書籍は、2016年6月にいたるまで、1冊も出ていません（追記:　2017年6月になってもまだありません…）。

PHPの中でも最速のフレームワーク？　…確かに

これは、使っているうちに実感できてきたのですが、ローカルや、無償枠の Heroku 上で使ってみても、なかなか速いと感じられました。

実際に計測された方の記事はこちら（「Phalconの何がいいのか速いのかに疑問を持ってみる」）。

例えばですが、何でもかんでも JS にしてしまう WebPack 、あれを使うより、高速にレンダリングしてくれているのではと思います。

WebPack の欠点は、何もかも詰め込んだJSが読み終わるまで、画面が固まることです。
Googleは、「ブロッキングJS」と呼んで、サイトの評価を下げるポイントとしています。

ライブラリをひとつにしてリクエスト数をおさえるのは確かにメリットがありますが、それもサイズを考慮しないといけないと思います。
その点、Phalconのレンダリング・スピードはなかなかのものでした。

AngularJS を知った時は、これからはフロントサイドの時代かなと思いましたが、サーバサイドもまだまだ捨てたものじゃない、とう印象です。

Phalcon の「方言」

実際、フレームワークを使ったことのある方なら分かる話なのですが、そもそもフレームワークでは、「プログラムの理解度」より、独特の「使い方を知る」ことが重要になってきます。

セキュリティや、難しいSQLを簡単にしてくれるツールですが、フレームワーク独自の使い方になっているため、たとえPHPのすべてを理解していても、そのフレームワークのことを何も知らなければ、何にもできません。

電子機器に詳しい人がいても、全長20mの工業用モンスタートラクターを運転するなら、その使い方は、一から学ばないといけないのと同じです。
もちろん、電子機器に詳しければ、何かトラブルがあった時に、細かいところに手を突っ込んで直したりもできるわけですが、そのフレームワークがどう動くのかは、別の知識、テクニックが必要になってくるわけです。

Phalcon が他のフレームワークと異なるのは、「DIコンテナ」とか、「依存性コンテナ」と呼ばれるものと、公開用ディレクトリの直下にある、「bootstrap」ファイルと呼ばれるものです（もちろん、Twitter の Bootstap のことではありません）。

DI という変数に使いたいクラスを宣言して入れておくと、フレームワーク内のどこでも使えるようになります。
考え方は、composer の autoload.php と同じです。
ただ、組み込み済みのクラスがいくつかあり、セッションとか、ログとか、APIを作るときのレスポンスとかはあらかじめ備わっています。
もちろん、composer と合わせて使うこともできます。

PostgreSQL が（そのままでは）まともに使えない

PHP のフレームワークと相性が良いのは、MySQL です。Oracle になると、CakePHP や　Yii では使えないことが多いです。

PostgreSQL を Phalcon で使ってみたところ、2つのテーブルを結合して、IDで紐づいた先の名前を出力したら、みんな最初の名前になるという、とんでもないバグがありました。

仕方ないので、Idiorm というPDOをラッピングしたライブラリを使用してみたところ、うまくいきました。
このあたりの切り替えというか、「あれがダメでもほかの方法があるに違いない」という発想は、ウェブのエンジニア独特のものかも知れません。
フレームワークだから何でもこれ1本で出来るはずだと思い込んでいると、先に進めなくなってしまい…この点も普及につながっていない理由だと思います
（例えば、Heroku の無償枠では、Postgreしか使えないので、ORM を自力で実装する発想が出てこないとここであきらめざるをえないでしょう）。

まあ、柔軟性があると言われている Phalcon 、モデルの代替も柔軟にできてしまうので、救われました。

便利なプラグインはほとんどない…まったくないわけではない、が…

CakePHP に比べると、ヘルパーの数も少なく、プラグインも見つかりません。
ほとんどないと思われますが、「デバッグツールバー」は、ありました。
最後に実行したSQLを出力してくれたり、リクエスト変数をすべて展開してくれたりと便利です。
他…ないんじゃないでしょうか。
CakePHP 派はイヤになるでしょうね。

使ってみて、意外と気に入りましたが…人にはすすめにくいフレームワークです

サーバによって、インストールできないことが多いであろう、Phalcon ですが、高速であることと、モデルやビューを簡単に好みのものに入れかえることができるので、海外では人気が高いようです。
海外では、Google App Engine のフォーラムで、Phalcon をサービスとして組み込んでもらうよう、票を集めているのを見かけました。

日本では…。
英語の壁とモデルのバグ、プラグインの少なさが災いしているのか、あまり実例を聞きません…。

私個人でも、もしフレームワークの選択をせまられたなら、初期の調査で対象から外したでしょう。
いかに高速でも。
理由は明快です。
ウェブの技術の基礎概念でもある「サポートする人間の数が多いほど、その技術は生き残れる」というものから外れているからです（この日本において。前述のとおり、海外では違います）。

日本では、「そもそも英語を読もうとしない」エンジニアが多いです。
また、英語を読まない人は、「変化」も好みません。

Phalcon というフレームワークの基礎の「骨格」を切り崩して機能を補充して使うようなやり方が、一般的なエンジニアにスムーズに受け入れられるとは、とても思えません。
シンプルで長続きするのは、「ドキュメントが充実」しており、「ググれば誰かが書いている」ほどの人気の高さです。
Phalcon に欠けているのはその2点で、そこが、この日本では難しいのです。
周りが日本人以外のエンジニアなら、何の気兼ねもせず推奨できるでしょうが…。

さて、マニュアルや記事が少ないので、とっかかりが大変ですが、さすがに実プロジェクトで半年もさわっていると慣れてくるものです。
ただ、習得する時間が膨大なものになりかねない点は、正直、運用面から怖いと言わざるをえません。

私の例でいうと、1年経って、システムがリリースし、運用が落ち着いてきたので、案件から外されることになりました。

英語も読めない、Pahalcon の根っこをさわったこともない、発注元が残ります。
PHP7 と、Phalcon 3に乗り換えるとき、どうするんでしょう…とは思いますが、どうも発注元は保守費用を自分のところで掌握したい様子。
ならリスクも込みで背負うということなのでしょう。
ドキュメントはすべて残しているので、分かる人がいるなら頑張ってほしいと思うだけです。
私だったらリスクの高さにおののきます。
まったく反対に、今でもアブナイのだから、バックアップ要員として、もう一人PHPエンジニアをつけるべきだと思うほど…ですが、何の告知もなく決定したことなので、もう何も言えない状態です。
こうやって、システムのリスクというのは、本来のプログラム的なところとは別の観点から高まっていくようです。カオスです。

話がややそれましたが、さて、動作が速く、「かゆいところにデフォルトでは手が届かないが、結構何とかなる」仕様は、意外と良いものです。
何ともならず、「独特の解決方法」を何時間もかけて探す、というようなことはあまりありませんでした（英語が読めれば…）。

私個人は、Rails から CakePHP、Yii2、そして Phalcon へと流れてきたのですが、Phalcon も気に入りました。
まったく、Google App Engine で使えたらいいな、と思います。

その後、2017年に入ってからは、Codeigniter が好きになりました。
理由は、オレオレフレームワークになりにくいこと、ディレクトリごとにグループ化したコントローラやモデルを作るのが直感的なこと、です。
設置もソースのアップロードですむし、多分、Phalcon の次にくるほど高速です。

Phalcon は、つくづく英語が重要になってくるフレームワークです。
それでもYiiよりはわかりやすい印象を受けました。ウェブ開発するならドキュメントのやさしい英語くらい読破したいものですが、どうしても苦手な人には難しいでしょう。

ドキュメントが日本語化されていることからも、Codeigniter はまったく、分かりやすくておすすめです。
高速だし、市販のマニュアルもあるから、こっちを採用すれば良かったのでは？　と思いますが、決定事項には逆らえないのが末端のエンジニアの宿命のようです（繰り返しますが、日本では）。

※2017年4月20日追記
もしフレームワークを選択できるなら、今なら保守性が高く、人気が高まっている Laravel を推します。
スピードはCakePHPなどより遅いようですが、ドキュメントは充実しているし、高速開発、保守性の高さから、Laravel を選びたいです。

※2017年6月18日追記
MVCを使いたい、よくある機能をオレオレクラスで実装したくない、ちゃんとそろっているものが欲しい！というのであれば Codeigniter がおすすめです。
CakePHP のような Scaffolding を出力する仕組みさえないものの、構造が実にシンプルで扱いやすいので、初心者向けかも知れません。
高速にMVCの仕組みで小規模のサイトを立ち上げるのであれば、これが一番だと思います。もちろん、APIサービスを作るのにも向いていると思います。