Next.js × Go モノレポ構成：4ポータル × 4APIを1人で保守する設計【第3回】
この記事で得られること Next.js + Go のモノレポ構成パターン pnpm workspace + Turborepo の実践的な使い方 4ポータルで共通UIを使い回す設計 ソロ開発で破綻しないパッケージ分割の考え方 はじめに 第1回で紹介した通り、Saruは4階層のアカウント構造を持つマルチテナントSaaSだ。これを実現するために、4つのフロントエンド + 4つのバックエンドAPIという構成を採用している。 普通に考えると、8つのリポジトリを管理することになる。ソロ開発では破綻する。 そこでモノレポを採用した。本記事では、その構成と設計判断を解説する。 1. なぜNext.js × Go なのか 技術選定の理由 領域 技術 選定理由 Frontend Next.js 14 App Router、RSC、豊富なエコシステム Backend Go + Echo シンプル、高速、型安全、デプロイが楽 DB PostgreSQL RLSによるマルチテナント分離 なぜフルスタックフレームワーク（Next.js API Routes）を使わないのか？ 関心の分離: フロントエンドとバックエンドのデプロイサイクルを分けたい 言語の強み: Goの方が複雑なビジネスロジックを書きやすい（個人の感想） スケーラビリティ: 将来的にAPIだけスケールさせる可能性 認証フローは以下の分担：Keycloakがユーザー認証、NextAuthがOAuth/セッション管理、Go APIはKeycloakのアクセストークン（JWT）を検証して権限チェックを行う。 2. プロジェクト構成 saru/ ├── apps/ # 6つのNext.jsアプリ │ ├── system/ # System Portal (管理者) │ ├── provider/ # Provider Portal (サービス提供者) │ ├── reseller/ # Reseller Portal (販売代理) │ ├── consumer/ # Consumer Portal (利用者) │ ├── customer/ # Customer Portal (レガシー名、consumerと統合予定) │ └── landing/ # ランディングページ │ ├── packages/ # 共有パッケージ │ ├── types/ # TypeScript型定義 │ ├── ui/ # 共通UIコンポーネント │ ├── api-client/ # APIクライアント + React Query hooks │ ├── auth/ # NextAuth設定 │ ├── config/ # ESLint, TypeScript設定 │ └── env-validator/ # 環境変数バリデーション │ ├── backend/ # Go バックエンド │ ├── cmd/ │ │ ├── system-api/ # System API (port 8080) │ │ ├── provider-api/ # Provider API (port 8081) │ │ ├── reseller-api/ # Reseller API (port 8082) │ │ ├── consumer-api/ # Consumer API (port 8083) │ │ └── migrate/ # マイグレーションCLI │ └── internal/ # 共通ロジック │ ├── e2e/ # Playwright E2Eテスト ├── pnpm-workspace.yaml # pnpm workspace設定 └── turbo.json # Turborepo設定 なぜ4つのAPIに分けているのか 「1つのAPIで全部まかなえばいいのでは？」という疑問があるかもしれない。 ...