Laravel はダメで時代遅れなんですか？

Posted at 2024-11-05

参考にした記事

https://qiita.com/MadakaHeri/items/e6034727fcab8b61b55e
こんな記事が話題になっていました。しかし、この記事の内容は妥当なのでしょうか。私の実感とはかけ離れていると思うので疑問に思う点を記述します。

それって本当ですか？

Laravelはオンプレ前提パート

以下引用

今はLaravelを本番環境で稼働させようとするとこうなると思います。
|WAF| - |LB| - |Nginxコンテナ| - |Laravelコンテナ| - |DB|

引用終わり

この図と文章の意味するところはよく分かりませんが、一口に本番環境でアプリケーションを動かすと言ってもその実行環境は様々です。例えばAWSを使うにしても、EC2のなかにPHPをいれてその上で動かしている環境も少なくはないでしょう。またコンテナの文脈においてもAWSではその実行や管理にECSを使うのか、EKSを使うのかでも状況は異なると思います。あと別にオンプレミス環境でもコンテナ技術を使うことは多分にあると考えられます。

どのような状態が通常かということは安易に決定できません。

そもそもオンプレとは

オンプレミスとは、システムの稼働やインフラの構築に必要となるサーバーやネットワーク機器、あるいはソフトウェアなどを自社で保有し運用するシステムの利用形態です。

ということであって、そのサーバー上でどのようにアプリケーションが動くかは不明確で自由です。そのようなものをフレームワークが前提にすること自体そもそも不可能だと思います。
私の知らないオンプレの話をしているのなら別ですが。

Laravelはオンプレ前提って本当ですか？

MVCフレームワークでは小さなアプリしか作れないパート

LaravelだけではなくMVCフレームワーク全体を公開処刑なさっています。
言うまでもないことですが、ここ10年以上の単位で世界を席巻した大規模と言えるサービスの中には、MVCフレームワーク、特にRailsを使ったものは多いです。
GitHubも、AirbnbもMVCフレームワークで作られています。まあこれらのサービスが小さいと言うのであればそれまでですが。
MVCフレームワークでは小さなアプリしか作れないって本当ですか？

以下引用

ではどこに使いまわせるパターンを書きましょう？モデルに書きますか？
モデルに書いてしまうとモデルが過剰に肥大化してしまいます。
テーブルに依存しない処理はどこに書きましょう？

結論、Laravelはそういうサポートを提供していません。

自力でフォルダ分けをして関数セットを内包するクラスを定義するしかありません。
そしてこれらはほぼ闇落ちします…
これが大きなサービスを作れない１つ目の理由です。

引用終わり

このような、MVCフレームワークにおけるモデルの肥大化問題や各種設計上の問題は別にLaravel固有の問題ではなく、あらゆるソフトウェア開発者が常日頃直面し解決を試みる問題だと思います。
Laravelがそのようなサポートを提供していないとは言っても、特にソフトウェア開発者の工夫を妨げるような構造をしているわけではありません。
また、このような設計上の問題をフレームワークのレベルで解決するのは困難だと思います。アプリケーション開発において直面するこのような問題は大抵の場合固有のものであったり、どの手段を取るのか開発者自身で取捨選択するものです。
なので、世の中には設計系の主張や書籍が溢れているわけですね。

更に続きます。
以下引用

単純にテストしにくいんですよ。
普通に関数セットを定義していればテスト、いやそれ以前に実行確認も簡単です。
関数内で $request からパラメーターを取り出してゴニョゴニョしていると入力をHTTP形式にせざるを得ない。

これはクリーンアーキテクチャ的にはアンチパターンであり、HTTP形式の入力がある部>分はプレゼンテーション層と呼ばれ、値の受け渡しのみしかしてはいけない場所です。
つまり、$request からパラメーターを取り出し、そのパラメーターを他の関数の入力に渡して結果をそのまま返す。
それ以上のことをしてしまうと中規模以上のものを作ろうとした時に破綻してしまいます。

引用終わり

これはもしかして、Laravel上で開発されたアプリケーションの一連の動作をテストしようとしているということでしょうか。
なかなかハードなことをしているなという印象を受けます。これもまた、特にLaravelが開発者の工夫を制限しているわけではないので、リクエストから値を取り出すような箇所と、本当にテストしたいロジックの部分を分離するというような実装方針をとればいいだけのことだと思います。この点に関して、Laravelが他のフレームワークに比べてやりにくいなどはないと思います。
クリーンアーキテクチャの部分はその主張の意味するところが正確には分かりませんでした。

更に続きます

問題３：ORMをModelとしている
中略
構成変更やデータ移行は必ず発生するため、テーブルがどのように使用されているかを把握することはかなり重要なのですが、そこらじゅうでクエリが書かれているとその把握ができなくなり、最終的にテーブルを一切さわれなくなります。
もうこうなったら詰みです。
リプレイスしか安全な方法が無くなってしまい、そのコストは計り知れません。
実際企業はコストを払ってくれませんから、エンジニアがサビ残をして不眠不休で作業することになる場合が多いと思います。（特にリーダー）
何であれ、夢も希望もありまてん泣

引用終わり

MVCフレームワークが定義するModelが他の文脈で使われるModelと異なることと、そこら中でクエリが書かれることによる実装把握が困難になることは全く別の問題だと思います。
別にLaravelであろうと、他のフレームワークであろうと任意の箇所でデータベースにクエリを投げる処理を書くことは可能ですし、そのような処理が本番コードに入り込んでしまうのはどんな場合においても設計やコードレビューの問題だと思います。
また、何度も書きますが、Laravelはそのような状況を避けるための開発者の工夫を特に妨げません。
また、企業がコストを払わないことやエンジニアのサビ残はもっとLaravelと関係がありません。

ダメで時代遅れなのはそのような遵法意識の薄い企業なのかもしれません。

問題４：「ディレクトリなんて好きに切れ」と言えない構造パート

この箇所に関しては首肯できる箇所がありました。それはフレームワークが自動生成するディレクトリ、コード類とバッティングしないような構造を決定しにくい。

ということです。これは同意できるところもある反面、大型フレームワークを使う以上は仕方がないことなのかなとも思います。
また、そもそもディレクトリ構造の決め方はこのようなフレームワークを使わなくても苦心するものだと思うので、試行錯誤するのはこれもまた避けられないことではあると思います。

最後に

これは私の感覚に過ぎませんが、参考にした記事は現代のソフトウェア開発一般に共通する悩みや労働問題を特定のフレームワークの問題にすり替えたもののように感じました。
そもそもフレームワークはそれを使うだけですべての開発方針が決まるものではなく、それらの便利機能をうまく使った上で工夫しながらソフトウェアやシステムを開発していくもののはずです。
故に、ソフトウェアの設計方針や手法には様々なバリエーションがあるのだと思います。

そのような前提はLaravelであろうと他のフレームワークであろうと同様であり、とりわけLaravelがそれらの点において特別劣っているようには私は感じません。何しろLaravelは筆者が問題としている点を回避したり工夫したりすることを特に妨げてはいないからです。