世間はGW一色ですが、自営業には関係ありません。

とはいえ、アポは入らないし、顧問先からの相談なども少ないため、こういうときこそ以前から気になっていた課題を解決する時間として活用すべきでしょう。

さて、私がずっと気になっていた課題が、

• 顧客サービスとしてLaravelで構築していたWebアプリのN+1問題

ループ処理の中で都度SQLを発行してしまい、大量のSQLが発行されてパフォーマンスが低下してしまう問題

【Ruby on Rails】N+1問題ってなんだ？

データベースを扱うWebアプリを安易に構築してしまうと、必ずこのN+1問題が生じるため、常に注意を払っておく必要があります。

N+1問題を発見する「Laravel Debugbar」

もちろん、注意しながらWebアプリを構築していたつもりですが、知らず知らずN+1問題を発生させてしまう場合もあります。

そのため、自分では気付けていないN+1問題を発見するため、「Laravel Debugbarについて」を参考に、Laravel Debugbarを導入しました。

なお、Laravel Debugbarを使用した様子は以下をご参考ください。

参考：Laravelでデバッグするならこれ！Laravelにデバッグバー(debugbar)を導入する方法

で、調べてみたら、Controllerの部分はほぼ大丈夫だったものの、Bladeの部分でやはりN+1問題を生じさせていました。。。😅

やはり、人力には限界があります。またヒューマンエラーも防ぎようがありません。そのためにもツールを有効利用すべきですね。

リファクタリングを通じて得た教訓

今回の教訓を備忘録として書いておくと、

• BladeでN+1問題が発生しやすい。Controllerのdumpだけでは発見しにくいので、Laravel Debugbarは必須
• withで引っぱることのできるテーブルは複数指定が可
• 引っぱったテーブルから、さらにテーブルを引っぱることができ、その場合は「.」でつなぐ
• return viewではなく、return redirectを利用する

つまり、以下のように書くことができるということです。

$post = Post::with('category', 'postcomments.user')->find($request->id);

また、今回、return viewではなく、return redirectが必須である理由を理解できたのは1つの収穫です。

LaravelのEloquentリレーションは便利ですが、奥が深く、常に勉強し続ける価値があります。

参考：Laravel 9.x Eloquent:リレーション