即席アプリテンプレ（単一ノード / 単一ポート / 最小構成）

ソースコードはこちら

これは何か

単一ノード・単一ポートで動くことにこだわった、即席Webアプリのテンプレです。
初期開発でありがちな「ポートが増える」「CORSやURLの環境変数が散らばる」「HTTPS/独自ドメインの設定が面倒」を、Caddyのリバースプロキシでまとめて解消することを目的にしています。

※本テンプレでいう「単一ポート」とは、アプリケーションとして外部に公開する入口を1つに集約する、という意味です。（HTTP/HTTPSの80/443はCaddyが吸収します）

構成

• Frontend: React + TypeScript
• Backend: Python + FastAPI
• DB: MySQL
• Reverse Proxy / HTTPS: Caddy（独自ドメイン + SSL終端）
• Orchestration: Docker Compose

こだわったポイント

1) 単一ポートで完結（CORS/ポート乱立/SSL設定を最小化）

フロントとバックエンドを別ポートで公開すると、開発初期から以下が地味に面倒になります。

• APIエンドポイントやCORS許可のために、似たようなURL環境変数がフロント/バックに散らばる
• ポートを複数解放する必要があり、ローカル・本番・検証環境で管理が崩れやすい
• HTTPS（独自ドメイン）を入れた瞬間に、フォワーディング設定や証明書周りの手間が増える

このテンプレでは Caddyを入口にして単一ポート化することで、上記の面倒を極力出さない設計にしています。

2) dev / prodをComposeのprofileで切り替え（コマンドはほぼ同じ）

Docker Composeのprofileを使い、開発と本番で「やること」を極力変えない方針にしています。

• 開発（dev）：ホットリロードありで開発できる
• 本番（prod）：フロントをビルドして Caddy から静的配信する
• どちらも「profileを変える」以外は、同じノリで環境構築できる

「環境ごとに手順が違って毎回ハマる」を避けるための設計です。

3) 初期開発は単一ノードで十分、あとから分離できる

フルマネージド（Lambda + DynamoDB など）はpay-per-useで安く見えますが、実際には周辺（API Gateway 等）を含めて構成が増えやすく、初期開発の速度が落ちることが多いと感じています。

このテンプレは、まずは小さなEC2等の単一ノードで動くことを前提にして、

• 開発人数や要求が増えたら、後からフロント/バック/DBを分離していける
• そのときもネットワークやポートの都合に引きずられにくい

という「後から成長させる」前提で組んでいます。

使いどころ（想定）

• PoC / 小規模Web / デモ環境を最短で立ち上げたい
• 早い段階から独自ドメイン + HTTPSが求められるが、設定地獄は避けたい
• とりあえず動くを作り、後から育てる前提で進めたい

補足（思想）

自分が嫌だったのは、初期段階なのに構成が複雑化して、
「ちょっと機能追加するだけでAWSサービスがつぎはぎになっていく」
「ローカル環境構築が面倒で、途中参加のエンジニアが入りにくい」
という状態になっていくことです。

だから、このテンプレはシンプルで再現性の高い入口を用意することに振り切っています。