第36回: キュー・ジョブ入門 — 重い処理を「バックグラウンド」に追い出す
ユーザーが「送信」を押してから数秒待たされるのは、UXを大きく損ないます。Laravelのキュー・ジョブを使えば、重い処理をバックグラウンドに追い出し、レスポンスを即時返せます。
Category
カテゴリー: 応用編
第35回: Laravelの認証（Breeze） — 認証を「ゼロから作らず」最速で導入する
ログイン・登録・パスワードリセットを自前で作るのは手間がかかるうえ、バグが入り込むリスクもあります。Laravel Breezeは認証機能を最小構成で素早く導入できる公式スターターキットです。
第34回: ミドルウェア — リクエストの「通過ゲート」で横断処理を集約する
同じ処理を複数のコントローラに書くと、修正漏れやロジックの不一致が起きやすくなります。ミドルウェアを使えば、HTTPリクエストの前後に共通処理を1箇所で定義し、ルートに適用できます。
第33回: フォームリクエストクラス — バリデーションを「コントローラの外」に出す
$request->validate([…]) をコントローラに直書きし続けると、メソッドが肥大化して可読性もテスト性も下がります。フォームリクエストクラスに切り出すことで、バリデーションと認可のロジックを1ヶ所に集約できます。
第32回: Bladeテンプレート — Viewを「読みやすく・再利用しやすく」組み立てる
を素のPHPで書くと、HTMLとロジックが混在してレビューしにくくなります。BladeはLaravel標準のテンプレートエンジンで、繰り返し・条件分岐・レイアウト継承を明快な構文で書けます。
第31回: コントローラとアクション — 「受け取る・判断する・返す」を明確に分ける
バリデーション・DB操作・メール送信……すべてをコントローラに詰め込むと、テストも修正も困難になります。コントローラはリクエストを受け取り、適切なレスポンスを返す「司令塔」に徹するのが正しい設計です。
第30回: ルーティング設計 — URLと処理を「一覧できる地図」に整える
ルーティングの定義が散漫になると、バグ修正の際にどのファイルを触ればいいか迷いが生じます。Laravelのルーティングを正しく設計することで、アプリの全体構造を一目で把握できる「地図」が手に入ります。
第29回: Laravelのインストールと構成 — 最初の一歩を確実に踏み出す
フレームワークを使い始めるとき、最初の環境構築でつまずいてしまい、そこから先へ進めなくなる経験は多くの学習者が通る道です。Laravelは機能が豊富なぶん、「どの手順を・どの順番で・何を確認しながら」進めるかが曖昧なまま始めると、エラーの原因すら特定できない状態に陥りがちです。
第28回: APIバージョニング — 既存クライアントを壊さずに進化させる
レスポンスのフィールド名を変えたり、必須パラメータを追加したりすると、既存のモバイルアプリやフロントエンドが動作しなくなります。全クライアントが同時にアップデートできるとは限りません。
第27回: レート制限の実装 — 「1分60回まで」でAPIを守る
認証なしのAPIエンドポイントは、悪意のある大量リクエストや誤ったループ処理によって、サーバーリソースが枯渇する危険があります。結果として、全ユーザーへのサービス品質が低下します。