#60 – Sensaciones con firestore
Preparando audio para descarga.
Escucha patrocinada. El audio empezará en pocos segundos...
Escucha sin anuncios y sin esperas con iVoox Premium
Pruébalo Gratis
Preparando audio para descarga.
Escucha patrocinada. El audio empezará en pocos segundos...
Escucha sin anuncios y sin esperas con iVoox Premium
Pruébalo GratisEste audio le gusta a: 8 usuarios
Premium
Plus
Comentarios
me ha pasado lo mismo que a ti, yo tb venia de Bd Sql y al pasar a No-sql sin back, he tenido que cambiar mucho la manera de pensar. Al no usar cloudFunction, q actuarian como un trigger de sql, para hacee los cambios de x ejemplo cuando cambia el nombre cambiarlo en toodo los doc q lo contengan, es bastante farragoso. En mi caso el modelo de datos es bastante complejo y contiene muchos datos. ya he visto mas de 1 vez lo de cuota execedida... Lo que he aprwndido es a definir cada wntidad cmo si se tratase de un json gigante y para determinar estos triggers determinar donde son cambiados y ver a donde deben propagar el cambio. Y hay varias cosas importantes, tener varios getters que parseen solo lo necesario, tener una fechas de actualizacion para cada doc y guardar una cache para evitar hacer mas peticiones(lo malo es q es una cache a nivel de dispositivo, no de server, aunk se podria emular de server usando firestorage). Tener colecciones que se crean cuando se solicitan la primera vez. Lo que no funciona es tener los datos sin repetir en el firestorage y q el cliente haga de back, consultando de diferentes docs para formar el vm cada vez. Cuanto mas volumen de datos y menos repeticion de los datos maa prpbable el maldito error de cuota excedidad. Gracias por el podcast, me parece muy interesante