このサイト本体と、複数のサブドメインで公開する個人開発アプリを、どのようにリポジトリへ分けるかで少し迷いました。 結論としては、サイト本体と各アプリを、それぞれ別のリポジトリで管理しています。

モノレポにしなかった理由

最初はモノレポも検討しました。 1つのリポジトリで管理すれば、共通コンポーネントを使い回しやすくなり、設定や依存関係もまとめて確認できます。 ただ、このサイトと個人開発アプリでは、それぞれ性質がかなり違います。

  • Next.jsのバージョンをアプリ間で揃える必然性がない
  • DBや認証を使うアプリと、静的に完結するサイトが混在する
  • 開発や公開停止を、ほかのアプリに影響させず完結させたい
  • 環境変数やデプロイ設定をアプリ単位で独立させたい

もちろん、モノレポでもアプリごとに依存関係やデプロイ先を分けることはできます。 ただ、そのためのワークスペース設定やCIの条件分岐を、個人開発の初期段階から維持するメリットはあまり感じませんでした。

共通化で得られるメリットより、性質の異なるアプリを1つのリポジトリで管理し続けるコストの方が大きいと判断しました。

共通UIは最初から共有化しない

複数のアプリを作る前提だと、共通のUIコンポーネントを最初からパッケージ化したくなります。 ただ、現時点ではまだやりません。

理由は、共通化すべき境界線が、アプリを作る前には見えないからです。 1つ目のアプリを作り、2つ目を作り、そこで初めて「ここは共通化した方がいい」という箇所が具体的に見えてきます。 見た目が似ているだけでは、まだ共通コンポーネントにする理由としては弱いと考えています。

複数のアプリで同じ理由から変更されるようになって、初めて共有化を検討します。 それまでは、多少の重複を許容します。 早すぎる抽象化は、あとから設計を剥がすコストの方が高くつくからです。

リポジトリとDBの分割単位は別にする

もう1つ判断材料になったのが、Supabaseの無料枠です。 無料で使えるプロジェクト数には限りがあるため、すべてのアプリに個別のSupabaseプロジェクトを用意する構成は取りにくいと考えました。 ただし、リポジトリを分けることと、DBプロジェクトを分けることは別の判断です。

小規模な実験アプリであれば、1つのSupabaseプロジェクトを共用してもよさそうです。 一方で、個人情報の扱いや認証要件が異なるアプリは、DBプロジェクトも分離した方が管理しやすくなります。 リポジトリの分割単位と、インフラの分割単位を一致させる必要はありません。

後から変えにくい部分だけを先に決める

構成を決めるときは、つい最初からきれいな設計を作りたくなります。 ただ、実際にアプリを作って運用してみないと、共通化すべき場所も、分離すべき場所もわかりません。

今回は、アプリ同士を独立して動かすためのリポジトリ境界だけを先に分けました。 一方で、UIの共通化やDBプロジェクトの分離は、必要性が見えてから判断します。 最初から完成された構成を目指すのではなく、後から変えにくい部分だけを先に決める方針です。