LaravelのつらみとこれからのBackend - スマレジエンジニアyushiのブログ

毎週の社内勉強会で、バックエンドのシニアエンジニア（役職じゃないけど、立ち位置として）の先輩に色々話を伺ったので、記録として本記事を書くことにしました。

※ 以降自分の意見のように書きますが、ほとんど先輩の話の受け売りです笑

最近の社内の新規開発ではLaravelを採用されることが多いのですが、フレームワークの構成と機能を活用して楽に開発できる一方で、つらい部分もあります。

Laravelは、HTTPやORMはもちろん、ストレージ管理やバッチ処理、フロントエンドのテンプレートなどおよそBackendとしての基本機能を全て内包したようなフレームワークです。

そのおかげ技術選定にこまることもいちいちフレームワークを追加することもなくサクサク開発できます。

一方それは難点でもあり、それらの利用を前提として開発を進めてしまうと、個別の置き換えがしづらくなってしまいます。

例えば、bugfixのためDBライブラリだけ指定のものと違うバージョンを利用するとか、より有用なライブラリに置き換えるとか、...。

最近のLaravelのアップデートは目新しいものがあまりなく、Laravel公式の有料サービスとのつなぎこみ機能や細かい機能修正ばかりで、また逆に破壊的な修正がパッチバージョンでリリースされることもあるそうです。

代替案としては、全部乗せのLaravelを使う代わりに、必要な機能に合わせて個別にライブラリを選定していくことです。

例えばSlim Framework（HTTP）、Atlas（ORM）など...

DDD風の構成ではロジックとライブラリは分離されるので、Laravelにこだわる必要もますます無くなります。

これは実際に採用もされていて、うまくいっているそうです。

ただ、こう言う方式だとライブラリ選定やアーキテクチャ設計から始める必要があり、求められるスキルは高くなります。

過去の記事にも書いた通り、PHP自体（というか動的型付け言語）がしんどいので、これから脱したいというのもあります。

そうなると、今だとGoだとかと言う話になってきます。。最近も軽く書籍をさらってみたりしているが、これについてはあまり知見がなく今後の課題という感じです...。

自分のレベルを考えると、スピーディかつ確実な成果を状況だとまだLaravelを採用したくなってしまいます。

タイミング的にはGoを取り入れてみたいところなのでこれのキャッチアップをしつつ、ちょっと冒険できるようなタイミングで採用してみたいです。