Desain Schema Firestore dengan Claude Code: Mulai dari Query

Firestore sebaiknya dirancang dari query

Saya Masa, pengelola claudecode-lab.com.

Kesalahan pertama saya saat memakai Firestore adalah mendesainnya seperti database relasional: users, posts, comments. Kelihatannya rapi, tetapi begitu muncul kebutuhan layar nyata seperti daftar post terbaru, halaman author, draft admin, dan halaman tag, schema itu mulai tidak nyaman.

Firestore bukan database yang bisa dibereskan belakangan dengan JOIN. Mulai dari query, lalu desain dokumen.

Referensi resmi:

• Firestore best practices
• Firestore index overview
• Firestore pricing

claude -p "
Desain Firestore untuk CMS.
Sebelum membuat collection, buat daftar query per layar.
Sertakan where/orderBy/limit dan composite index.
"

export interface PostDoc {
  id: string;
  slug: string;
  title: string;
  status: "draft" | "published" | "archived";
  lang: "ja" | "en" | "es" | "ko";
  authorId: string;
  authorName: string;
  tagSlugs: string[];
  tagNames: string[];
  publishedAt: FirebaseFirestore.Timestamp | null;
  updatedAt: FirebaseFirestore.Timestamp;
}

Duplikasi field kecil seperti authorName bisa mengurangi jumlah read di halaman daftar. Index juga sebaiknya disimpan di Git:

{
  "indexes": [
    {
      "collectionGroup": "posts",
      "queryScope": "COLLECTION",
      "fields": [
        { "fieldPath": "lang", "order": "ASCENDING" },
        { "fieldPath": "status", "order": "ASCENDING" },
        { "fieldPath": "publishedAt", "order": "DESCENDING" }
      ]
    }
  ]
}

Hasilnya, ketika saya memakai workflow ini untuk artikel, kontak, dan log, lebih dari separuh schema awal perlu direvisi. Claude Code paling berguna ketika diminta membuat tabel query dan risiko sebelum menulis implementasi.