I have an app that displays a list of items. Here is what I am doing.
When the app first loads I am making an HTTP request to get the list from the firebase database.
once the list is received the list is stored locally on localStorage for future use.
On future app loads, the list is loaded from localStorage to prevent unnecessary http calls
I am doing the above programmatically, i.e, saving data to localStorage and check for new data and getting it etc.
Does firebase provide any other way to the same?
There is no built-in support for cross page-reload persistence in the JavaScript SDK for the Firebase Realtime Database. Somebody is working on such functionality in the open-source repository, but no release was made with it yet.
If you need this functionality, I highly recommend looking into using Cloud Firestore. In addition to many other benefits, it supports cross page-reload persistence.
Related
I am currently creating a marketplace mobile application from scratch and I'm using React Native for the front-end part and Firebase for the backend (using Firebase and Firestore).
I am wondering wether :
I should create a RESTful API using cloud functions and express to create API endpoints (that would connect to firebase and firestore) that I'd call from my redux actions in my React Native app (using redux thunk).
or, I should call firebase and firestore directly from redux actions.
I see couple pros and cons for each method.
Restful API pros :
Safer as I can check and manipulate submitted data more easily
Custom API reply (I can manipulate the return data)
Restful API cons :
Probably slower as I would have to call an API endpoint that will then call firebase and/or firestore.
Won't be as easy to set listeners on firestore data
What do you think about it ?
Which option should I choose knowing that I predict that the app will get a few thousand users daily. I want it to be as fast and safe as possible and be able to set listeners for notifications purposes.
In my opinion you should mix them, if you have to manage users, products or etc. Firebase produces client and admin sdk that has different roles. If you haven't need manage any data of products or users or etc. you can simply use client sdk.
My advise is you can use admin sdk on API (server-side) and feel free to use client sdk on your clients.
Use as managements on API, listening data, realtime chat etc. via client sdk.
You can check admin and client sdk. Also npm packages for React Native here.
Mixing will be of help, you can try:
Listen for small amounts of data using the client SDK
Write and sort data using the cloud functions
In my experience, writing to a firebase database that uses ordered ids (in my case) leads to some huge problems in the long run. I lost a good chunk of data when my app accidentally wrote to a root index instead of a child index when the app was resumed from inactivity because the android system cleared the RAM.
Also, for notification, use Firebase Cloud Messaging.
I need to load some image files from Cloud Storage. For a given folder I need to check what images (if at all) are available in it. It seems like the firebase client library (https://pub.dev/packages/firebase_storage) doesn't have a simple way of doing that. I am sure ios/android clients have ref().list() command. Is there any way to do that easily in Flutter or I have to write a bridge to native methods?
The methods to list files in Cloud Storage were only recently added to the Firebase SDKs, so it seems likely that they haven't been ported to the FlutterFire library yet.
You'll indeed either have to implement the interop yourself (in which case a PR back to the repo is highly appreciated), or wait for someone else to implement this feature request.
A final alternative is to not depend on this (relatively new) API, and store the list of file paths/download URLs in another data store, such as the Firebase Realtime Database, or Cloud Firestore.
So I was watching multiple tutorials about how to present data on an actual webpage using Cloud Firestore. The thing is, everyone was using an actual index.html file sitting in Public folder(instead of serving html content within node.js code) and tags which would mean that their program would use client-side JavaScript instead of node.js. But why? for what reason? According to Firebase tutorials and documentation, having an ACTUAL index.html sitting in Public folder is only for making static webpages, thus, if I'm making a complicated and dynamic webpage(which will also present Firestore data within the webpage), I should be using node.js right?
The Firebase SDKs for Cloud Firestore perform local persistence (caching) of doucments fetched from the database. The persistence is enabled by default for Android and iOS, and you can programmatically enable it for web (currently experimental). This local caching allows the client to avoid requesting documents from the server, which is obviously faster and cheaper than going through some API endpoint to request the data each time it's needed.
There is also the fact that the SDKs will push you realtime updates of data as it changes on the server, as long as you have a listener attached to some document or query of interest. You won't be able to duplicate this if you write it all in Cloud Functions. You will spend a tremendous amount of time trying to duplicate and scale this behavior using socket.io or something similar on a backend you control.
You could write the entire app to be driven through API endpoints that you create. There's nothing wrong with that, if it meets your needs. But you'll write more code, you'll sacrifice realtime updates, and it will likely be slower and more expensive than allowing the client SDKs to optimize for you.
My iOS app's firestore cache seems to have got out of sync with Firestore. As a result I've had to disable persistence. Is there anyway to reset the cache? And is there a way to make sure it's constantly in sync? All I did was delete documents from the database!
There is now a feature in the API for clearing persistence. It is not recommended for anything but tests, but you can use
firebase.firestore().clearPersistence().catch(error => {
console.error('Could not enable persistence:', error.code);
})
It must run before the Firestore database is used.
There's no API for manipulating the local cache in any way. The Firestore SDK chooses what to store based on queries that you perform.
On Android, users can manually clear the local data for an app without uninstalling it. This will remove all the data locally stored by the app.
If you have a specific use case, please feel free to file a feature request.
My iOS app's firestore cache seems to have got out of sync with Firestore. As a result I've had to disable persistence. Is there anyway to reset the cache? And is there a way to make sure it's constantly in sync? All I did was delete documents from the database!
There is now a feature in the API for clearing persistence. It is not recommended for anything but tests, but you can use
firebase.firestore().clearPersistence().catch(error => {
console.error('Could not enable persistence:', error.code);
})
It must run before the Firestore database is used.
There's no API for manipulating the local cache in any way. The Firestore SDK chooses what to store based on queries that you perform.
On Android, users can manually clear the local data for an app without uninstalling it. This will remove all the data locally stored by the app.
If you have a specific use case, please feel free to file a feature request.