category: プログラミング
# Laravel

Laravelを使ってどんな技術構成を採れるか

投稿日 最終更新日

2025年09月27日

毎回悩んでる気がするので、ここで整理しておこうと思って。

前提

  • 私が理解している、知っているものしか書いてないです
  • シェア的な話が出てくるけど、そういうのはState of Laravelの2025年の情報やState of JavaScript 2024の情報を元に書いています
  • Web技術自体、流行り廃りが激しいので数年後にはどうなってるかわからんです

簡単な結論

めっっちゃ雑に言うと、以下のように分類できる

  • バックエンド
    • WEBサーバー
      • 従来型（PHP-FPM方式）
        • Nginx + PHP-FPM
        • Apache + PHP-FPM
      • 高速型（Octane方式）
        • Laravel Octane
          • Swoole
          • RoadRunner
          • FrankenPHP
    • アプリケーション
      • Laravel
    • データベース
      • MySQL系
      • PostgreSQL
      • SQLite
  • フロントエンド
    • モノリス型
      • SSR
        • Blade
      • SPA
        • React/Vue
      • SSR/SPA
        • Livewire
        • Inertia
          • React
          • Vue
          • Svelte
    • サーバー分離型
      • SSR
        • Next.js
        • ReactRouter
        • Nuxt.js

つまり、確定しているのはアプリケーションにLaravelを使うというところだけで、それ以外はめっちゃ自由。

それぞれメリットデメリットがあるので、雑に私の所感を書いていく。

バックエンド

つまり、サーバー側で処理する部分の話。

Webアプリケーションの3層構造に倣い

  1. Webサーバー
  2. アプリケーション
  3. データベース

という感じで分類している。

Webサーバー・従来型（PHP-FPM方式）

つまりはリクエスト毎にPHPの実行環境を初期化する方式のサーバー。

  • メリット
    • 成熟した技術なので安定してる
    • Octane方式と比較して圧倒的シェア(しらんけど)
    • 毎回初期化されるのでメモリ解放とか考えなくていい
  • デメリット
    • 高速型（Octane方式）と比較して遅い

主に

  • Nginx + PHP-FPM
  • Apache + PHP-FPM

のような選択肢がある。

NginxとApacheどっち選ぶかについてなんだけど、正直どっちでも良いかなとは思う。
ただ、LaravelのデプロイドキュメントではNginxが紹介されてるので、深い理由がなければNginxでいいのでは。

Webサーバー・高速型（Octane方式）

つまりはPHPの実行環境を使いまわすことで高速化を狙う方式のサーバー。

  • メリット
    • モダン
    • 処理内容によるけど、従来型のサーバーと比較してだいたい3倍〜10倍くらい早い
    • 非同期的に複数リクエストを一気に処理できる
  • デメリット
    • モダンすぎて情報ないし成熟もしてない
    • メモリ解放考えないといけない

主に

  • FrankenPHP + Octane
  • RoadRunner + Octane
  • Swoole + Octane

のような選択肢がある。

私はOpen Swoole + Octaneで使ったことあるんだけど、トラブルはほとんどなかったし設定もOctaneのおかげで簡単だし悪くない体験だった。

ただ、実績が少ないし、大規模+大量のアクセスで使ったことないので

  • 本当にそこまでのスピードが必要なのか？
  • もっと他にスピードのボトルネックになってるところがないか？
  • メリットとデメリットを天秤にかけたとき本当にメリット上回るか？

とかをよく考えて使う感じになるのかなと思う。

アプリケーション

Laravel万歳！

データベース

主に

  • MySQL
  • PostgreSQL
  • SQLite

のような選択肢がある。

MySQLとPostgreSQL

複数のアクセスがあるならMySQL or PostgreSQLのどっちかを選ぶ。

正直、PostgreSQLを使ったことがないので、ガチの雑感しか落とせないんだけど比較は以下のような感じ

  • MySQL
    • 成熟した技術
    • Laravel内ではPostgreSQLにダブルスコアでシェアNo.1
      • ただ、利用率は落ちてってる
    • PostgreSQLと比較してシンプル
      • 逆に言えばPostgreSQLの方が多機能と言われてる
  • PostgreSQL
    • ここ数年シェアを伸ばしてきてる
      • 2025年には前年比10％増
    • MySQLと比較して多機能らしい
    • つまり、トレンドってやつ

どっちを使ってもだいたいやりたいことはできるとは思うので、学習コスト気にならないならPostgreSQL、気になるならMySQLという選び方でいいのかなぁとは思う。
ただ、DBの移行って簡単ではないはずなので、慎重に選ばなきゃいけないのが辛いよね。

SQLite

もし、複数のアクセスがないならSQLiteをめっちゃおすすめしたい。
つまり、小規模だったり、個人利用向けに作る場合はSQLiteがよい。

特徴は以下

  • 簡単
  • サーバーレス
  • 1つのファイルに全てのデータ入る
    • 移行しやすい！
    • コピーしやすい！
  • RDBとして必要な機能は大体持ってる

とにかく、初めてSQLite使ったとき私は感動したよ。
仕組み上限界があるので、それなりの信頼・処理能力が求められると使えないんだけど、Koelみたいな各個人がインストールする方式のWebアプリとか、とりあえずLaravel動かしたいときとかにめっちゃ良い。

フロントエンド

つまり、HTML + CSS + JSをどう処理するかという部分。
バックエンドと比較して幅が広いし、廃り流行りが激しいし技術選定が難しい。

また、分類をモノリス型とサーバー分離型という分類にしてみた。

厳密にはInertiaもSSRするならNodeサーバーが要るのでサーバー分離するっちゃするんだけど、「なんか、だいたいLaravelの中に含まれるよね！」っていうのがモノリス型。
バックエンドのみにLaravelを使い、フロントにまた別サーバーを作ってAPIで通信させるのがサーバー分離型。

ちなみに、サーバー分離型でLaravelを使ったことがないのでそこら辺は完全にエアプです。

モノリス型

モノリス型って明確な定義はないと思うんだけど、強いていうなら以下のような感じ

  • 単一プロジェクトで構成される
  • バックエンド/フロントエンドで完全に分離されていない

小・中規模開発ならだいたいモノリス型を採るんじゃないだろうか。

SSR・Blade

いっちゃんデフォルトなフロントエンドの作成方法。

PHPを使いBladeという記法でHTMLを書き、サーバー側で処理してHTML化して、それをレスポンスする方式。

  • メリット
    • SSR
    • シンプル
  • デメリット
    • Bladeを使ってモダンにしようとすると魔改造の道へ進むことになる

こうやって考えてみると、別にモダンを求めなければBladeってそんなにデメリット無いね。
この記事で言うモダンは「画面の部分的な更新ができる」ことを指している。

SPA・React/Vue

一応Inertiaとかを使わなくてもReact/Vueは利用できる。

実際に私が見たことある実装方法としては

  1. 最初のリクエストへはほぼ空のBladeを返す
  2. そのBlade内でReact/Vueを起動して以降は、SPA的にReact/VueでLaravelと非同期通信して処理する

という感じ。

  • メリット
    • モダン
    • React/Vueが使える
  • デメリット
    • 自力でReact/Vueの初期化処理書かないといけない
    • API設計しないといけない
    • SSR対応できない

今はInertiaがあるし、わざわざこの構成にする意味も薄いかなぁという気はする。

Livewire

Alpine.jsという軽量フレームワークを利用して作成されたフレームワークがLivewire。

PHPを使ってモダンなフロントエンドを書けるのが特徴。

  • メリット
    • SSRかつ動的な実装がPHPだけでできる
    • Alpine.jsを使って独自のJSも書ける
    • Laravelで動的なフロントエンドを作成する目的でLivewireはシェアNo.1
      • Vueと0.5％差なので僅差ではある
    • LaravelスターターキットにLivewireの項目が存在する
  • デメリット
    • フロントエンドフレームワーク全体でみるとLivewireは少数派
    • Laravelエコシステムへの依存度がかなり高くなる

PHPを使ってSSRかつ動的な実装ができるというのはLivewireの大きなメリットだとは思う。ただ、私はLivewireを学んで使うならInertia+React/Vueを学んで使うかなと思っている。
理由は、デメリットに上げた通りLivewireってLaravelとの組み合わせでしか使わないし、React/Vueが使えたほうが他にも応用が効くので。

Inertia.js

LaravelとReact/Vue/Svelteの橋渡しを簡単にしてくれるのがInertia.js。

つまり、Inertiaを使えばReactの初期化処理を苦労して書かなくていいし、API設計とかもしなくて良い。

  • メリット
    • React/Vue/Svelteが使える
    • SSRもできる
    • LaravelスターターキットにInertiaの項目が存在する
  • デメリット
    • 2023年に正式版になったばかりで新しく、情報が少ないし成熟はしていない
    • Inertiaへの依存度がそれなりに高くなる

Inertiaを使うと簡単にReactなどと連携ができるようにはなるんだけど、だからといってバックエンドとフロントエンドの完全分離がされるわけではない。
API設計をしなくて良い代わりにInertiaの関数を通した通信を行うので、必然的にそれに依存することになる。
ただ、そういうったことを抜けば素晴らしいツールなのかなと思っている。

サーバー分離型

つまりは、バックエンドにLaravelを使い、フロントエンドでまたNext.jsやNuxt.jsなどのフレームワークを使ってAPI通信をさせるといった方法。
つまり、Webサーバー+フロントエンド用のNodeサーバーの2台構成になる。

実際に私はこの方法をやったことがないけど、ﾂﾖﾂﾖエンジニアや大規模なWebアプリケーションでこの構成が取られているイメージ。

  • メリット
    • バックエンドとフロントエンドが完全に分離できる
      • つまり、どっちかだけ技術を一新するということが比較的簡単に可能
      • 分離して開発できる
    • API通信なので、モバイルアプリとかにも展開できる
  • デメリット
    • サーバー台数が増える
    • 学習コストが高い
      • Laravelに加えてNext.jsまで学ぶとなると、慣れるのにどれだけかかることやら
    • 実装コストも高い
      • もちろんやることは増えるよね

一時期血迷ってこの方式を採ろうとしたことがあるんだけど、個人開発でやることじゃないなと思ってやめた。
しかも、これ別にLaravel咬ませる必要あるのか？　という気もしてしまう。
ただ、ロマンはあるし、長くこだわって開発したいなら全然アリな選択肢かなと思っている。

おわりに

Laravelってそれなりに柔軟だからこそ選択肢が多いし、初心者の頃とかこれだけの選択肢を把握するのは絶対ムリだったのでこんな感じでまとめてみました。

なにか新しい選択肢を発見次第更新したいと思います。
以上です。

category: プログラミング
# Laravel