Laravel、Django、FastAPI。アプリの構成を見比べる

個人で開発したアプリの構成例を比べ、入力した値が画面から保存先へ届く流れを見ます。Laravel・Django・FastAPIは、どれもアプリ開発の土台（フレームワーク）です。Laravelは店舗とレビュー、Djangoは写真付きの日記、FastAPIは商品管理と利益計算に使われています。これらの作例で、画面と処理の分担を比べます。

LaravelとDjangoは、入力から保存まで追う

店舗とレビューの作例は、サーバー側の処理を組むLaravelに、画面を作るReactと、両者をつなぐInertiaを組み合わせています。Laravelの公式資料。

この作例を見るなら、フォームに入力した値がどこへ届き、どこで検証され、保存後にどの画面へ戻るかを追います。フレームワークの名前だけでなく、画面と処理をつなぐ部分まで見ると、構成をつかみやすくなります。

日記の作例はDjangoで、保存形式・入力欄・処理を分担し、DB（データの保存・検索を担う仕組み）には軽量なDBのSQLiteを設定しています。Djangoの公式資料。日記を入力して詳細を表示するまでを、同じ枠組みの中で読めます。

FastAPIでは画面と計算を分ける

商品管理の作例は、Reactの画面とAPI（画面から処理を呼ぶ窓口）を作るFastAPIを分けています。利益計算もPythonの関数に分かれています。FastAPIの公式資料。

画面とAPIを分けると、送る項目と返す項目を決める必要があります。利益の数字が合わないときも、入力値、計算、表示のどこを見るかが変わります。私は構成を比べるとき、この切り分けが追いやすいかを見ます。

商品管理の calculate_profit は、売価から仕入れ値・手数料・送料を引き、利益を返す関数です。画面の処理とは別のPython（プログラミング言語）のファイルに置かれています。

NestJSとNext.jsは、担当する場所が違う

イベントを日報につなぐ作例には、サーバー側の処理を組むNestJSを使っています。保存処理を仲介するPrismaと、DBの一種PostgreSQLを指定しています。

営業管理の作例は、画面やサーバー処理を組めるNext.jsの画面とLaravelのAPIを組み合わせています。

どちらもJavaScriptに型の指定を加えたTypeScriptで書けますが、名前を横に並べるだけでは比較しづらいです。ブラウザに表示する部分なのか、リクエストを受けて保存する部分なのか。作例の中の担当を見てから比べる方が、私には分かりやすいです。

DBの保存先と、起動方法まで見る

DBも、日記はSQLite、会計管理はMySQL、日報はPostgreSQLという構成です。

日報の作例には複数の実行環境をまとめて起動するDocker Composeの定義もあります。DBを選んだ後に、そのDBをどう起動し、データをどこに置くかまで追えます。

次に構成を選ぶときは、入力画面を一つ決めて、検証、計算、保存、表示を順にたどります。使う技術の数より、その経路を自分で説明できるかを目安にします。個人開発アプリの作例にも、それぞれの構成を載せています。