Open4

【WIP】技術選定の変遷【初期開発からリリースまで】

技術選定
Prisma
Supabase
Cloudflare Workers
cloudflarekv
NaNNaN

開発環境バックエンド構成（2025/7/17）

各ツール詳細

Supabase DB (PostgreSQL)

  • 用途: メインデータベース
  • 環境: Supabase クラウド
  • アクセス方法:
    • API Workers経由でのデータアクセス
    • バッチ処理での統計集計
    • 開発ツール（Prisma、Supabase CLI）での管理

Supabase Auth

  • 用途: 認証・認可
  • 環境: Supabase クラウド
  • アクセス方法:
    • フロントエンドから直接認証
    • APIでのトークン検証

Cloudflare KV

  • 用途: キャッシュストレージ
  • 環境: Cloudflare Workers KV
  • アクセス方法:
    • API Workersでのキャッシュ取得
    • バッチ処理でのキャッシュ書き込み

Cloudflare R2

  • 用途: 音声ファイル等のオブジェクトストレージ
  • 環境: Cloudflare R2
  • アクセス方法: API Workers経由

Cloudflare Images

  • 用途: 画像ファイルストレージ
  • 環境: Cloudflare Images
  • アクセス方法: API Workers経由

開発環境アーキテクチャ

  1. スキーマ設計: Prisma でDBスキーマを定義（マスター）
  2. マイグレーション: Supabase CLIでマイグレーション実行
  3. 型生成: Drizzle でPrismaのDBをintrospectして型生成
  4. 開発: Supabase の Web UI で直接確認・操作可能
NaNNaN

dbの構成を細かくした図、最初はsupabaseCLIのみのシンプルな構成だったが様々な仕様に答えるためにここまで複雑になってしまった。最終的にはdrizzleのみに統一予定。
今はコマンド一つでdbリセットが働き、schema変更できるようにしているため、認知不可は０。

開発期間のDB管理構成

NaNNaN

feature/home,workと分けていてもqueryやschemaがかぶる場合は、shared分けるのがよい。
なんでもかんでもsharedにしてると可読性が崩壊するので、完全に独立しているものだけ。
今回work-card.schemaとそれを取得するqueryをquery-builderとして分離。
あとsharedに入れているのはpriceInt,workIdといったprimitive型、header.schema、tag.schemaだけ。
componentで考えると分離しやすい。

NaNNaN

schema.prismaではbigintの型をどう扱うかを詳細に定義できない

  model TrxWorkChapter {
    id        BigInt   @id @default(autoincrement())
    chapterId BigInt
  }
  - BigInt型の扱い方を指定できない
  - DBには純粋なBigInt型として定義される