はじめに

私はLaravelが好きです。
この記事では、Laravelの良いところと弱点を紹介しつつ、Laravelとしっかり向き合う方法を話します。

自己紹介（誰が書いたのか？）

普段は、PHP・Laravelでバックエンドエンジニアをやっています。
立ち位置的には、ジュニアとシニアの中間くらいかと。
AWSやフロントエンド周りを扱うことも多々あります。

PHP系フレームワークの経験では、Symfony4~5、CakePHP2~3は、昔の業務で軽く触ったことがあります。
FuelPHP、Yiiも新人時代にちょっとだけ触りました。

そんな私がLaravelを好きな理由を、この記事に記載します。

PHPフレームワークの選択肢としてのLaravel

Laravel以外のPHPのフレームワークの選択肢は、もちろん複数あります。
SymfonyやCodeignitorやCakePHP、Yiiなどです。

Stack Overflowの2024年の調査によると、
PHPのフレームワークにおいては、Laravel, Symfony, Codeignitor, Yiiの順で人気があるようです。
（WordPressも上位に食い込んでますが、ここでは省略します

次の項目では、私がLaravelを好きな理由と合わせて、Laravelの長所を紹介します。

私がLaravelを愛する理由

Laravelエコシステムの充実

公式トップページにもあるように、複数のLaravelエコシステムがあります。

例を挙げると、認証まわりにおいては、SanctumやBreeze、JetStream。
OAuth IdM利用のためのSocialite、IdP構築のためのPassport。
ローカル環境のdockerをサクッと構築できるSail。
Laravelのためのインフラを構築できるForge。
StripeやPaddleでサブスクリプションや購入まわりを構築できる Casher。
他にも、フロントエンドでPHPを書けるLivewireや、オンメモリで高速に動くOctaneなど。

一部を記載しましたが、これだけのことが公式のエコシステムで実現できることは魅力だと思います。

他にもLaravelの人気からAWSやエコシステムに限らず、様々なユースケースに対応するライブラリが豊富なことも、私がLaravelを愛する理由です。

AWSとの親和性

公式ドキュメント上で紹介されているように、S3やSES、SQS等をほぼそのままで使えることが好きです。

ファイルストレージはS3、MailerはSES、キュージョブはSQS、セッション・キャッシュはDynamoDBにそれぞれ対応しています。

また、MailerはPostmarkやMailgun、キャッシュはMemcachedやRedisなどの他のサービスにも対応しているのもミソです。
もちろんサードパーティでCognitoなどの他のAWS関連のライブラリがあります。

このように、ストレージやメールなど、よくあるユースケースをAWSサービスを用いて素早く構築できることが強み です。

また、StorageなどのFacadeのメソッドは抽象化されているため、使用するサービスに左右されずに使えることもメリットだと思っています。
（一方で、Facadeはどこでも使えてしまうため、やたらめったらに使うと、コードの結合度が上がり、複雑性が増すデメリットはあります

充実のドキュメント

ドキュメントが見やすく、Laravelの基本的なところから応用まで網羅されています。

また、本体のアップデートに伴って、既存のページも頻繁に更新されていることも要チェックです。

Laravelの人口の多さ

例として、クラウドワークスで検索すると、Laravelを扱えるフリーランスの人は7,000人います。
Symfonyは700人程度、Codeigniterは50人未満です。

このように、エンジニア市場において、Laravelを扱える人間は集めやすいと思います。
（あくまで人口の多さのみにフォーカスすると、ですが

Laravelの弱点

Laravelの好きなところを挙げましたが、Laravelは完全無欠のフレームワークではありません。
Laravelの弱点を確認し、じっくり向き合います。

頻繁なメジャーアップデート

Laravelは1年ごとにメジャーアップデートが行われます。
1年ごとにアップデートがあり、EoLは2年後です。
（昔はLTSがあったのですが、6あたりを最後になくなったと記憶しています。

このように、Laravelで作ってメンテし続けるのであれば、頻繁なメジャーアップデートに対応するための工数を割く覚悟を持たねばなりません。

自由度の高さゆえのカオス

無差別なFacadeの使用や制約のないDIは、放っておくとカオスを招きます。
また、ビジネスロジックを記述する場所も特に制約されておらず、プロダクトによってまちまちになりがちで更にカオスを産みます。

国内Laravelコミュニティの弱さ

Laravelの国内人口は多いようですが、国内コミュニティはまだ海外に負けています。
Laracon US・EU・AU（オーストラリア）はありますが、日本国内ではLaraconはまだ開催されていません。

いつかLaraconが日本で開催され、更に国内のLaravel熱が高まると思うとワクワクしますね。

Laravelとの向き合い方

このように、Laravelの弱点として、頻繁なメジャーアップデートと、カオスを生む自由度とは、私たちは向き合い、戦い続けなければなりません。

では、どう向き合うのか？

テストコードはしっかり書こう

当たり前かもですが、テストコードはきっちり書きましょう。
頻繁なメジャーアップデートに対して、テストコードを書いていれば、最低限の動作を担保でき、プロダクトに対するダメージを最小限に防げます。
もしテストコードを書いていないのであれば、それはもはや未来の負債といえるでしょう。

未来のアップデートのダメージを最小限にするため、テストコードはキッチリ書いておきましょう。

良い設計を追い続けよう

この設計なら何があっても未来永劫バッチリ！とは、なかなか言えません。
1人のエンジニアとして、設計の試行錯誤とブラッシュアップを欠かさずに行いましょう。

他の人の書籍や発表かもしれませんし、自ら得た教訓や成功体験を経て、良い設計を追い続け、無秩序なカオスをしっかり対策しましょう。
Laravelで何かを始めるときは、Laravelの開発・保守経験を複数経験した人がいると、しっかり安定してくるイメージがあります。

最後に

私はLaravelが好きです。
パワフルで、スマートで、書くのが楽しいフレームワークだと思っています。
他のフレームワークを使う業務では、ライブラリやエコシステムの少なさから、Laravelだったらなぁ...と思うことが多々ありました。
また、今までの経験から得たLaravelの良さを伝えたいと思い、この記事を書きました。

テストを書いて良い設計を追い続けることで、アプデに耐えてカオスを減らし、しっかりLaravelと向き合える気がします。
どちらも他のフレームワークにも共通する向き合い方にはなってしまいますが、Laravelのメジャーアップデートの頻度を考慮すると、テストの重要性は高いです。

国内コミュニティはどんどん活発になってほしいですが、Laracon をするなら何が必要だろうと思い、Laracon USやEUが個人的に気になってきました。

みなさんも良いLaravelライフを！

明日、Fusic Advent Calendar 2024 4日目の記事は @spihill さんが書きます！
みなさんお楽しみに！