個人開発アプリを複数サブドメインで公開する構成にするとき、リポジトリをどう分けるかで少し迷った。結論としては、アプリごとにリポジトリを分けるマルチレポにした。
モノレポにしなかった理由
最初はモノレポも検討した。1つのリポジトリで全部管理できれば、共通コンポーネントの使い回しも楽になる。しかし個人開発アプリはそれぞれ性質が違いすぎる。
- Next.jsのバージョンがアプリごとにずれる
- DBを使うアプリと使わないアプリが混在する
- 公開時期もアプリごとにバラバラで、片方だけ止めたいこともある
- デプロイ権限や環境変数もアプリ単位で分けたい
これらを1つのリポジトリで扱おうとすると、CI設定やデプロイフローが複雑になる。共通化のメリットより、分離のコストの方が大きいと判断した。
共通UIは最初から共有化しない
複数アプリを作る前提だと、共通のUIコンポーネントを最初からパッケージ化したくなる。ただ、それはまだやらない。
理由は、共通化すべき境界線がアプリを作る前には見えないからだ。1つ目のアプリを作り、2つ目を作り、そこで初めて「ここは共通化した方がいい」という箇所が具体的に見えてくる。それまでは重複を許容する。
早すぎる抽象化は、後で剥がすコストの方が高くつく。
Supabaseの無料枠という制約
もう1つ判断材料になったのが、Supabaseの無料枠が所有プロジェクト合計2つまでという制限だ。リポジトリを分けることと、DBプロジェクトを分けることは別の判断にした。
小規模な実験アプリは1つのSupabaseプロジェクトを共用してもいい。個人情報や認証要件が異なるアプリだけ、DBプロジェクトを分離する。リポジトリの分割単位と、インフラの分割単位を一致させる必要はない。
構成を決めるときは、つい「きれいな設計」を先に考えてしまう。でも実際に運用してみないとわからないことの方が多い。今回はコストと柔軟性を優先して、判断を後回しにできる部分は後回しにした。