Café y Código

5. Firestore: colecciones y reglas 🛡️

Modelado mental

Cada documento tiene un ID único dentro de su colección. Podés anidar subcolecciones cuando tiene sentido agrupar datos “bajo” un usuario o una entidad padre (por ejemplo usuarios/{uid}/notas).

Firestore no es SQL: las consultas compuestas tienen reglas (índices compuestos, limitaciones de or en ciertos casos). Conviene diseñar el modelo pensando en qué listados vas a mostrar en la app.

Ejemplo conceptual (SDK web)

Con el SDK de Firebase v9+ en modo modular, el flujo típico es obtener referencias a documentos o colecciones y luego getDoc, getDocs, setDoc, onSnapshot, etc.

SDK modular (v9+)
JAVASCRIPT
1 import { doc, getDoc, setDoc } from "firebase/firestore";
2
3 // Leer un documento
4 const snap = await getDoc(doc(db, "perfiles", uid));
5 if (snap.exists()) {
6 console.log(snap.data());
7 }
8
9 // Crear o sobrescribir (cuidado: define bien las reglas)
10 await setDoc(doc(db, "perfiles", uid), {
11 nombre: "Ana",
12 actualizado: new Date()
13 });

En apps reales, actualizado suele ser un Timestamp de Firestore, no un Date de JS crudo, según cómo configures el cliente.

Reglas de seguridad (imprescindible)

Firestore no debe quedar abierto a todo el mundo en producción. Las Security Rules definen quién puede leer o escribir qué rutas, normalmente en función de request.auth.uid tras iniciar sesión con Firebase Auth.

Regla de oro: el cliente nunca es de confianza. Todo lo que no esté prohibido por reglas puede ser abusado. Probá reglas con el simulador de la consola antes de publicar.
Ko-fi
Donaciones
Apoyá cafeycodigo con un café en Ko-fi. Colaboradores: insignia, muro y zona exclusiva.
Ir a Ko-fi → Programa sponsors