Tipos de datos en Cloud Firestore y cómo estructurarlos
Presentación
Firebase Auth
Cloud Firestore
Cloud Storage
Cloud Functions
Curso Firebase para Web se encuentra en desarrollo. Vuelve pronto para encontrar nuevas lecciones.
- En esta lección te explicaré las tres opciones esenciales para estructurar los datos en Cloud Firestore, pero antes quiero repasar contigo algunas reglas importantes que tienes que tener en cuenta.
- Los documentos tienen límites: 1MB de tamaño y 20.000 campos. Puede parecer una locura de tamaño si tenemos en cuenta que almacenaremos texto, pero si no planificas bien tu estructura es relativamente sencillo llegar al límite. Si te preguntas cómo guardar archivos como imágenes en alta resolución en 1MB, la respuesta Cloud Storage, que veremos más adelante 😺.
- Cuando hagas una consulta o lectura (que veremos muy pronto) no puedes retornar parte de un documento sino el documento entero. Tenlo en cuenta ya que no tiene sentido descargar información que no vas a utilizar.
- Las consultas no retornar sub-colecciones anidadas, sino únicamente los documentos asociados (shallow queries).
- Se te cobrará por la cantidad de operaciones de lectura y escritura, por lo que (una vez más) debemos de organizar los datos de la forma más inteligente, buscando un equilibrio entre coste y código mantenible.
- Teniendo esto claro, es hora de saltar a la consola de Cloud Firestore y jugar con los documentos, colecciones y sus tipos de datos.
- Dentro de tu proyecto, si es la primera vez que accedes a Cloud Firestore tendrás que activar/crear la base de datos y elegir la zona geográfica más cercana a tu localización. Además se te preguntará con qué set de reglas de seguridad comenzar. Elige modo prueba. Más adelante hablaremos de qué son las reglas de seguridad Firestore y cómo se utilizan.
- En la consola, podemos crear colecciones y documentos. Estos, como ya sabes, no son más que un montón de pares de key-value, como los objetos nativos JavaScript.
- Puedes añadir tú mismo/a el ID del nuevo documento o dejar que Firestore lo cree de forma única por ti, lo cual es casi siempre la mejor opción.
- Ahora podemos añadir los campos que queramos, eligiendo un tipo y un valor.
- Como ves, en la documentación de Firestore se muestran todos los tipos válidos. La mayoría son auto-explicativos, aunque quizás haya algún un poco extraño como
map, el cual se refiere más o menos a un objeto nativo,referenceque permite guardar un path hacia documentos y subcolecciones para futuros accesos ogeopointque permite guardar las coordenadas de latitud y longitud de un punto geográfico. - Por ejemplo podemos añadir un usuario en la colección users con algunas propiedades. También podemos crear una subcolección dentro del usuario, creando así una relación jerárquica directa, y añadir en ella meta información como por ejemplo los gustos personales o favoritos del usuario en forma de tags, quedando algo así:
users/USER_ID/meta/favorites/tags. - Quizás te estés preguntando si no podríamos añadir los tags favoritos en el propio documento del usuario. La respuesta es depende. Bienvenido/a al mundo NoSQL 😉. Todo depende del contexto. En este ejemplo tendría sentido, pero si además de favoritos guardamos información que no se necesite de primeras, estaríamos añadiendo más datos al documento y, recuerda, como hemos visto estos tienen sus límites.
- De todas formas el saber cómo estructurar los datos en Cloud Firestore es vital. En la propia documentación se presentan las formas básicas. Así que vamos a echarles un vistazo.
- La primera opción es, como ya hemos visto, añadir todo en el propio documento. Esto tiene la ventaja de que la información es accesible con una única lectura de la base de datos. La desventaja reside en que no es escablable ya que los documentos tienen sus límites.
- La segunda opción consiste en crear sub-colecciones, de esta forma no aumentamos el tamaño del documento principal y creamos una relación padre/hijo. Una de las limitaciones es que no se pueden eliminar de forma sencilla desde el cliente, pero para ello podemos crear una Cloud Function, que más adelante veremos.
- La tercera y última es crear colecciones de nivel principal (root level collections). Estas son perfectas para relaciones many to many (imagina tener que buscar en las subcolecciones de cada usuario, por ejemplo). El problema es que, a medida que los datos aumenten, mostrar contenido de forma anidada o jerárquica será más complicado.
- Toda esta información irá cobrando sentido a medida que avancemos en el curso de Vue Firebase. Palabra.
El primer headless CMS tanto para desarrolladores como para marketers. Pruébalo gratis.
¿Tienes alguna pregunta sobre esta lección de Curso Firebase para Web?
Resuelve todas tus dudas sobre Firebase en la Comunidad de Escuela Vue: un lugar donde participar, aprender y ayudar. ¡Te esperamos!.
Tras el registro (si no lo has hecho ya) serás redirigido/a al canal adecuado en la Comunidad.