Desenhe Firestore com Claude Code: comece pelas consultas

Firestore deve começar pelas perguntas da aplicação

Sou Masa, operador do claudecode-lab.com.

Meu primeiro erro com Firestore foi pensar como em banco relacional: users, posts, comments. Parece organizado, mas quando a interface precisa de posts publicados, posts por autor, drafts no painel e páginas por tag, o schema começa a atrapalhar.

Firestore não é um banco que você corrige depois com JOIN. Primeiro liste as consultas, depois desenhe os documentos.

Referências oficiais:

• Firestore best practices
• Firestore index overview
• Firestore pricing

claude -p "
Desenhe Firestore para um CMS.
Antes das collections, liste as queries por tela.
Inclua where/orderBy/limit e índices compostos necessários.
"

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;
}

Duplicar pequenos campos de exibição, como authorName, reduz leituras extras em listas. Índices devem ficar versionados:

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

Na prática, esse fluxo me fez reescrever mais da metade do primeiro schema. O maior ganho foi pedir ao Claude Code a tabela de queries antes do código.