Concevoir Firestore avec Claude Code : commencez par les requêtes

Firestore se conçoit depuis les requêtes

Je suis Masa, l’opérateur de claudecode-lab.com.

Avec Firestore, j’ai d’abord conçu des collections comme dans une base relationnelle : users, posts, comments. Le problème apparaît lorsque l’interface demande des listes réelles : articles publiés, articles par auteur, brouillons du back-office, pages par tag. Firestore n’est pas une base que l’on corrige ensuite avec des JOIN.

La bonne méthode consiste à lister les requêtes, puis à concevoir les documents autour d’elles.

Références officielles :

• Firestore best practices
• Firestore index overview
• Firestore pricing

claude -p "
Conçois Firestore pour un CMS.
Avant les collections, liste les requêtes par écran.
Inclure where/orderBy/limit et les index nécessaires.
"

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

Les petits champs d’affichage peuvent être dénormalisés pour réduire les lectures. Les index doivent être versionnés :

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

En pratique, ce workflow m’a obligé à réécrire une grande partie de mon premier schéma. Le gain vient du fait que Claude Code rend visibles les requêtes, les index, les coûts et les règles avant d’écrire l’implémentation.