この記事は 第二のドワンゴ Advent Calendar 2019 の 9 日目の記事です。
モダン PHP という言葉に表されるように、PHP は PHP 7 の登場によってそれなりに普通の言語として扱えるようになってきました（いろいろと語弊があるかもしれません）。
時を同じくして、一定の規模を超えるサービスや人員を抱える組織を中心に、Web アプリケーションの開発方法も大きく変わってきました。これまで一般的だったモノリシックなアーキテクチャを避け、Mircroservices でつくる動きが主流となってきており、多方面でさまざまな取り組みが行われています。
この記事は、Microservice 時代における PHP を用いた開発はどうなっていくのかをぼんやりと考えるなかで書かれたお気持ち文書です。内容にまとまりはありません。
その PHP はどの PHP
一口に PHP といっても、認識している PHP に齟齬のある場合があり、「その PHP はどの PHP か」問題がしばしば起きるため、あらかじめ認識を合わせておく必要があります（以下は独断による分類です）。
- 2010 年代後半:
PHP 7.x - - 2010 年代前半 :
PHP 5.3 - 7.x - 2000 年代 :
PHP 4.x - 5.2
今も 2 や 3 のコードをメンテナンスし続けている現場は多く、そうした現場の PHP はだいたいステレオタイプな PHP の姿をしています。企業や人々は諦めてそのコードの寿命を待っているか、もしくは涙ぐましい努力のもとなんとかしようと取り組んでいるのが現状で、1 のコードとは程遠い場所にあるケースも珍しくありません。
この記事内における PHP とは、特にことわりがない限り 1 に当てはまるバージョン 7 以降の PHP を指すものとします。
Laravel の印象
かつては群雄割拠の世だった PHP 製フレームワーク界隈ですが、Laravel の登場以降、それまでに勢力を誇っていたいくつかの PHP 製フレームワークは一気に失速することとなりました。現在は事実上 Laravel 一強の世界になっています。
Laravel が急速にユーザ数を増やした一番の要因は、優れた開発体験にあると自分は考えています。学習コストの低さ、書き心地、手に馴染んでからの全能感…それはもうなんでも作れるんじゃないかといった気持ちにさせてくれるものです。
また、複雑な問題を解消するエコシステムが公式によって提供・メンテナンスされていることも大きいでしょう。エコシステムには信頼性や持続性、サポートなどの要素が求められますが、善意によるサードパーティの努力だけでは限界があります。だからこそ公式によるエコシステムの提供には意味があって、ユーザが Laravel を選択するモチベーションになり、結果として裾野を広げることにつながっているのかもしれません。
Laravel の良さは、Laravel のやり方に則っているときに引き立ちます。開発体験の良さも然りで、Laravel を採用するのであればどっぷりと Laravel のやり方やエコシステムに浸かることが Laravel の恩恵を最大限に受けることに繋がると感じています。
一方で、Laravel のやり方は自然に Laravel とコアドメインが密結合するやり方のため、一定以上の規模や複雑度を持つアプリケーションにそのまま適用できるものではありません。決して Laravel が大規模開発に使えないというわけではなく、一定以上の規模や複雑度を持つアプリケーションを、メンテナンス可能な構造を保ちながら Laravel で作るにはそれなりの知識と工夫が求められるということです。そこを見誤って、開発体験の良さがもたらす生産性があだとなり、あっという間につらいコードの山を築いてしまうなんてこともよくある話です。
（工夫した結果、Laravel を基盤とした単純なレイヤー化アーキテクチャができあがり、これは Laravel じゃなくても良いのでは…と頭を抱えるまでがテンプレです）
結局は使いどころという話ではありますが、小〜中規模のフロントエンドを含むモノリシックなアプリケーションをさくっと作る上で、Laravel が有力な選択肢であることは間違いありません。
Mircroservices 時代の PHP
そもそも Mircroservices を実装する上で PHP が選択肢になるのかという疑問はありますが、FasS 基盤をメインに据えて設計する時代が来たとき、あるいは RoadRunner や Swoole が頑張って RESTful API 以外の通信規約をそれなりのコストでクリアできるようになったとき、はじめて選択肢のひとつになり得そうと思っています。
ただ、そのときに使われるのは Laravel ではなく、他の何かだろうということをぼんやりと考えていました。Microservices の文脈において、単純に Laravel のような重量級フレームワークは求められないと予想しています。そして求めるべきではないという空気を作っていく必要がありそうです。
なぜなら Mircroservices は「なにをどう作るか」に加えて「いつどう捨てるか」ということもある程度計画されるべきだと考えるからです。サービスや組織、あるいは政治や時代によって最適なアーキテクチャは変化していくもので、現に Mircroservices もそうした変化を受けてのひとつの流れに過ぎません。時間を経てより良い選択肢が浮上した場合にも、スムーズに統廃合のムーブを採れる状況を維持することが重要であり、基本的にシンプルなやり方を選ぶことが望ましいと思います。
Microservice 時代の PHP において、基本的に人々が必要とするのは単純な DI とルーティングのしくみなのではないでしょうか。
マイクロフレームワークの機運
無用な抽象化を避けた素朴なインフラストラクチャ層はシンプルに強みで、これからは HTTP の入出力だけを上手くやるマイクロフレームワークの機運がより高まっていくのではと予想しています。あるいは PSR-7 / PSR-15 / PSR-17 が整備されたいま、好みの PSR 実装を用いて素朴なインフラストラクチャ層を自前で用意しようというケースも増えていくのではとも思っています（半分冗談ですが）。
HTTP 以外に欲しい機能があるなら外部のパッケージを利用すればよく、必要に応じてカスタムを重ねていけば…その先に人々はいつかの Laravel や Symfony の姿を思い浮かべ、また頭を抱えるのかもしれませんが、それでもなおより良い答えを模索していく強い気持ちが大事になってくるのだと感じています。
まずはマイクロフレームワークから育てていこう、という話はもっとあっても良いはずですが、エンジニア採用の面でリスクになり得そうなものは使いにくいという気持ちも理解でき、なかなか難しいよなあというのが今の気持ちです。
Rasmus Lerdorf 氏の「PHP は歯ブラシである」という言葉は本当に PHP をよく表していて、Microservices 時代であっても hoge 時代であっても、単純な道具としての PHP に流行り廃りなんてなく、今後も使い続けられることは間違いないことだと思っています。そこに時代の流れがあればその時代に適応するぞというなりふり構わないスタイルが道具としての PHP のすごさ（かつ反則さ）であり、今の時代の流れを受けて PHP がどのように変わっていくかを楽しみにしています。
