Комментарии 9
На мой взгляд, firestore больше подходит для постоянного хранения данных, тогда как realtime бд для временных (или не совсем важных), которые требуют быстрой синхронизации, хотя спорно, если это чат. Было бы интресно узнать о подводных камнях или что под капотом кэша этих технологий. Например, спотыкаюсь постоянно, что закэшированные данные не вызывают ошибку загрузки, когда это необходимо (да, можно задать source server у документа, но этого нет у коллекции). У realtime бд аналогичные есть проблемы, пока я с этим разбираюсь. Кэш — вещь нужная, потому что мне никто не будет платить, если я по своей воли буду добавлять в проект Room или IndexedDB для экономии ресурсов, в ТЗ вы это наврятли когда-н. увидите отдельным пунктом. Надо разбираться как правильно работать с тем, что идет из коробки. А так статья совсем для новичков
Я не думаю, что firestore вынуждает вас не использовать кеш. Иначе бы система кеширования не шла бы из коробки.
Единственное, насколько я слышал, клиентский кеш firestore слабоуправляемый, и больше похож на то, как сам браузер кеширует данные.
И дополнительный слой кеша никто не запрещает реализовывать. Только вот проблема в том, что на практике, проще заплатить за лишние 1кк запросов в день, чем писать впопыхах кеширующий слой.
нет, для холодной хранилки уж лучше пользоваться Storage API и хранить снапшотами.
Firestore — это realtime database 2.0. И обе вполне подходят для realtime-приложений — вроде чата со счетчиком лайков. Просто Firestore удобнее и более гибкая. Ни разу не жалею, что пересел с лица Realtime database на Firestore одобрение.
Единственное, насколько я слышал, клиентский кеш firestore слабоуправляемый, и больше похож на то, как сам браузер кеширует данные.
И дополнительный слой кеша никто не запрещает реализовывать. Только вот проблема в том, что на практике, проще заплатить за лишние 1кк запросов в день, чем писать впопыхах кеширующий слой.
firestore больше подходит для постоянного хранения данных
нет, для холодной хранилки уж лучше пользоваться Storage API и хранить снапшотами.
realtime бд для временных (или не совсем важных), которые требуют быстрой синхронизации, хотя спорно, если это чат.
Firestore — это realtime database 2.0. И обе вполне подходят для realtime-приложений — вроде чата со счетчиком лайков. Просто Firestore удобнее и более гибкая. Ни разу не жалею, что пересел с лица Realtime database на Firestore одобрение.
Тогда существенная разница только в том, что у realtime ограничение по одновременному подключению, а у firestore это счетчик чтения/записи документов. Ну и по структуре: в realtime данные следует представлять в mapping структуре, когда у firestore это априори массив, не считая данные документа, который ограничен по размеру. Кэш везде слабоуправляемый
Статья затрагивает довольно простой пласт документации. Было бы здорово, если бы вы выпустили вторую часть статью про счетчики. Они всегда были головной болью что SQL, что NoSQL.
Но в Firestore появился недавно
Но в Firestore появился недавно
FieldValue.increment(). А также не забудьте рассказать и про шардирование. Оно, конечно, в рамках to-do приложения как собаке пятая нога, но если вдруг ваша тудушка станет популярно-залайканной, без него никак.
распиши более подробнее об режиме доступа, как настроить, с примерами
Спасибо за интересную вводную!
На сколько я понял из этой и пары других статей (коих пока мало про Firestore), Firestore, благодаря своей модели хранения данных, решает бОльшую часть проблем, описанных, например, в этой статье.
На сколько я понял из этой и пары других статей (коих пока мало про Firestore), Firestore, благодаря своей модели хранения данных, решает бОльшую часть проблем, описанных, например, в этой статье.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cloud Firestore + Android это просто