今のLaravelが如何にダメで時代遅れか
どこかに書き並べていきたいが…
Octaneとか関係なく、そもそもの設計の話で、Laravelのドキュメントに翻弄されてメンテ不能になってる会社が多過ぎる。
Laravelによる経済的ダメージは計り知れない…
とりあえずアウトラインだけ
・本番デプロイ方法が非公開
・あるべきアーキテクチャ
・何でも出来るORMがModel
・標準で関数セット置場が定まっておらず、テストがHTTP形式になる
・apiルートのオプション化
・OSSは収益化できてナンボ
・OSSと様々な思惑
基本の考え方としては「触らなくていいコード」を目指した実装にすること。
コントローラーに入ってくる$Requestからそのまま入力を取り出してORMでゴニョゴニョするのはNGで、そこはプレゼンテーション層だと言う意識を持つこと。
Laravelの中がプレゼンテーション層なのであれば、つまり他に定まったインターフェース（SDK）が必要と言うこと。
そこから目を逸らさせて「これ一本で何でも出来る強強フレームワーク」を名乗るのは悪なんですよ。
結果どこもかしこも密結合だらけ。
ここで今思ってること並べても伝わる気がしないけど、最終的にはただのHTTPルーターからSDKに橋渡しするだけの構成が1番シンプルで負債化しにくいと思う。
Eloquent ORMの代替で有名なのが出るだけでLaravelは終わる。
ORM界隈もGQLに寄ったり混沌としてるし、なんなら生SQLで良いまである。
生SQLは良いですよ。
ワイがHello worldやってた時代に書いたSQLがまだ使えるんですもの。
寿命の長い言語は良いですよ。
PHP、Composerのコンビとか極悪過ぎる。
あ、そうそう。
lumenはサ終しました。
Octaneが出来たので今後は全部Laravelでやってくれとのこと。
設定周りもう少し強化してくれてたらlumen一択の世界線もあったのに…
ほんと考えが全く合わない。
補足
ORMをあの位置でモデルとするには何でも出来すぎるんですよ。
テーブルがどう操作されてるか把握するには全てのコントローラーメソッドを追わないといけない。
非公式でリポジトリパターンとかありますが、それこそがモデルであって、ORMはその下のレイヤーに位置しないと危険なんです。
結論として、Laravelの立ち位置はWordPressを卒業した人の最初のステップにフィットしたものになってる。
（ここで大衆のイメージとかけ離れてる）
だからオンプレ前提だし、SSR推しだし（MVC）、画面とサービスのインターフェースをごちゃ混ぜにしてる。
これで大きなもの組もうとすると失敗する。
マイクロサービスが必要なレベルになると建て付けの階層が浅過ぎて崩壊するんです。