laravelとReactの構成で悩んだからGPTに相談した話
アプリ構成をGPTに相談する
これから小規模のWebアプリケーションを作成します。
Laravelはまだ知見が浅いので、今後のメンテナンス性を加味して構成などを決めようと思います。
条件
・フロントエンドはReact
・バックエンドはLaravel
仮説
最初は管理のしやすさから下記の構成を考えていました。
root/
├ backend/
└ frontend/
なんでこの構成かというと、frontでエラーが起きても、バックエンドへの影響を最小限に抑えられると考えたからです。また、実際に制作会社でこの構成を使って制作をしていたのをみていたので、正直最初はこの構成一択でした。
試作で怪しい雲行きに
試作でこの構成を使い、簡易的なアプリを作ってみました。が、CORSエラー...冗談抜きで丸1日溶けました。これはCORSについて勉強が別途必要。ローンチは遠のいたかと不安になっていた時に見つけたのが、この構成です。 laravelの中に、jsxを同居させます。
どの構成がいいのかGPTに聞いてみた
現在悩んでいる二つの構成を比較してもらうことにしました。
プロンプトの「プ」の字もないような人間っぽい質問
「curl -s "https：//laravel.build/example-app" | bashでlaravelの中にreactを組み込むのと、npx create-react-app frontendから作成してrootの中にbackendとfrontendを分けて構築するのと、どっちがいいと思う？」
構成の名前なども分からないので雑な質問になったものの、さすがGPT先輩。理解が早くて助かります。
構成の名前が判明
以下、ChatGPTの回答です。
Laravelの中にReactを組み込む（Monolithic構成）
メリット
フロントエンドとバックエンドが1つのリポジトリで管理できる。
デプロイや環境構築が簡単になる。
API不要で、BladeテンプレートとReactを組み合わせられる。
デメリット
フロントエンドとバックエンドの密結合で柔軟性が減少。
大規模アプリでは管理が煩雑になりやすい。
フロントエンドとバックエンドを分離（Microservices的構成）
メリット
フロントエンドとバックエンドを独立して開発・デプロイ可能。
フロントエンドを他の技術（Next.jsなど）に切り替えやすい。
チームで役割分担しやすい。
デメリット
API通信が必須。
セットアップやデプロイが複雑化。
結論
小規模/シンプルなプロジェクト：Laravel内にReactを組み込む。
中～大規模/拡張性が必要：バックエンドとフロントエンドを分離。
プロジェクトの規模とチームのスキルセットで判断してください。
選定の判断基準を質問する
目下5000人ユーザーを目指して居るならどう判断するか？
さっくり5000人ユーザーを目指して居るので、その視点からの判断を仰いでみる。
判断ポイントはユーザー数ではなく、同時接続数やトラフィックの性質
以下、ChatGPTの回答です。
1. Monolithic構成が適するケース
負荷が限定的
- 同時接続数がそれほど多くなく（例: 数十～数百）、大半のリクエストが簡単なCRUD操作である場合。
- データベースやサーバーが5000人の処理を問題なく処理可能。
システムのシンプルさを重視
- 開発リソースが少ない場合（小規模チームや一人で運用）。
- 機能追加や保守が複雑化しない。
トラフィックの変動が少ない
- ピーク時のアクセスが集中せず、分散されている。
メリット
- 開発と運用がシンプル。
- サーバー管理が単一の環境で完結する。
- 機能間の通信が同一サーバー上で高速。
2. Microservices的構成が適するケース
負荷が高い/ピークが予測される
- 5000人のうち、多くのユーザーが同時に接続（例: 1000以上）し、負荷が集中する場合。
- 高頻度なAPIリクエストやリアルタイム性が求められる場合（例: チャット、動画ストリーミング）。
- 機能が高度に分離可能
異なるチームが独立して機能を開発している。
- フロントエンドとバックエンドが異なるプラットフォームをターゲット（例: Webとモバイルアプリ）。
- スケールアップが必要
将来的にユーザー数が1万人以上に成長する見込みがある。
- フロントエンドやバックエンドを別々にスケールアウトすることでコスト効率を最適化したい。
メリット
- フロントエンドとバックエンドを独立してスケール可能。
- 特定の機能に障害が発生しても、他の機能への影響を最小化できる。
- 複数のプラットフォームで再利用しやすいAPI設計が可能。
切り替えポイントの目安
切り替えの判断は単純なユーザー数だけでなく、同時接続数やトラフィックの性質に依存します。以下を参考にしてください。
ユーザー数の目安
～5000人（通常はMonolithic構成で十分）
同時接続数が数百未満の場合、Monolithicで問題ありません。
5000～10,000人（状況に応じて検討）
ピーク時にトラフィック集中が予測される場合、Microservices的構成を検討。
10,000人以上（Microservices的構成が望ましい）
負荷分散、スケールアップの効率化が重要になるため。
同時接続数の目安
- 同時接続が500以下：Monolithicで十分。
- 同時接続が500～1000：サーバー負荷次第でMicroservicesに切り替えを検討。
- 同時接続が1000以上：Microservices的構成に移行したほうが安定。
GPTのいうことを鵜呑みにするのも怖いので
そもそもMonolithic構成とMicroservices的構成という言葉が実在するのか調べてみた。
まずはMonolithic構成
AIも回答できるほど明言されているらしい
モノリシック構成と読むらしいことが判明。実際、一つのモジュールで構成されているアプリケーションとの記載があった。
Microservices的構成は造語
やっぱりね。「的」といれているあたり、マイクロサービス的構成の方は造語っぽいなと思ってました。
今回はMonolithic構成を選択
まず最低限のスタートを切るのがローンチに必要だと考えて、Monolithic構成にします。
API通信とセキュリティに関する知識を深めつつ、サービスを育てて、構成を分けていこうという判断です。
多分その頃にはサーバーの見直しなども考えるタイミングでもあるので、目安としてちょうどいいかもしれません。その前にWebでなくAppにするのが先かも。
これが、地獄のフラグにならないことを切に祈りつつ、それくらいサービスが広がりますように！と地獄を願っている自分もいます。
Discussion