As Firestore charges by the read/write, it would be super helpful to keep the changes in memory during the session and only commit them when the user exists either the entire app or a specific section. Is there a way to do that in a Flutter web application?
I think one problem with this approach is that the user might just close the tab including your app. In this case, you have no time to send your data to Firestore.
This aside, you could use packages like Hive to store your documents offline and later run a function to add the data to Firestore later.
You also have 50k reads and 20k writes for free with Firebase, which is sufficient for smaller apps. If you exceed this limit, your app is probably big enough to earn money with it anyway.
Related
I wanna create a chatapp for my friend, and now remote serve I will use firestore and locally sqlite, but I realized it is default for firestore to save data offline, so my question is I have some data like message, or sending setting for the app, is it ok just to save them in firestore offline which seems automatically and no extra costs.
It depends on what you want or need.
If you want to use the offline persistance only for storing in case internet is not there at all. Firebase supports that out of the box. But you need to keep in mind to do you calls carefully. Because on a slow internet connection, if you tell the Firebase access to wait for the online behavior. It will not be using the local first and you might not be able to show the data. Check the question here
Also if you want to use the offline persistance from Firebase, be mindful that the data size has a default of 40 megabytes of limit. You might assign that by your self. You can check this link
BUT, if you want to have heavy data manipulations and have more control over your data SQLite is more suggested.
My opionion: I think Firebase Offline persistance would be enough for you, so go for it.
My page is quite small it has around 300-1000 visits each day. But at some point I started to accumulate HUGE firestore read requests:
Till the 8th date it was somewhere around 50K each day. I am pushing new code all the time so I'm not sure what I did. Looking at the page I don't see anything out of ordinary. Is there some sort of log in google or firestore I could look at?
The Firebase documentation indicates that each time you create a project, it also creates a project in Google Cloud Platform, therefore you can track daily Cloud Firestore usage like writes, deletes, etc. This usage information is shown in the GCP's console in the App Engine Quotas page .You can see more details in the link. https://firebase.google.com/docs/firestore/monitor-usage#google-cloud-platform-console
There is currently no way to track the origin of reads. What you're looking at now is the best indicator you have available.
Bear in mind that the Firebase and Cloud consoles show updates to documents in real time, and each document update costs a read. If you leave the console open on a busy collection, it will rack up reads.
In my web app, an authenticated user can pick songs from his spotify playlist to play at a party. I want guests (nonauthenticated users) to be able to view the picked songs on a dynamically created react route and vote on their favorite songs on their own device (probably a phone).
I am using a Mongo, Express, React/Redux, Node stack.
Since the guests don't have access to my app's redux store, the only way they can view the authenticated user's picked songs is through a GET request to my app's database. My initial plan was to just store playlist documents, and the users can GET those playlists to make a request to the spotify api. However, they are unauthorized and need an access token. This means that my database has to store every single one of the songs that the authenticated user picked.
My question has to do with design. I don't think it's a good idea for my one document to hold every song because some people might want to pick thousands of songs, and one document won't be able to hold all of the songs. On the other hand, creating a separate document for each song seems a little bit too excessive.
Can anyone help me figure out which option is better, or if there is a different option I haven't thought of that can avoid this problem altogether? Thank you
Assuming that if you would store each song in a separated document, the main disadvantage of this strategy is the space complexity, you'll need more space to store all documents.
But, supposing you'll keep all song documents at the same collection, it gives some advantages, for example: queries and sorts operations will be more flexible and faster. It helps you to save both processing and development time. A similar logic is showed here.
Use just one document to store all songs makes your database operations more complex, what requires more development time and code to organize all retrieved data on the proper way. Another disadvantage is that it isn't a long term scalable strategy, mainly because the limit of a BSON document is 16MB.
At my vision, the design of separated documents for each song is more appropriate and the reasons are:
Space is monetarily cheap.
Save time complexity must be a priority on all points of software development. Database queries usually are the slower operations in a software. So, reduce the cost of time at database operations is a good objective to seek. Storing all documents in one collection instead of in one document will retrieve all data already organized, with no no need to retreat at code.
Q1) I am designing a iPhone app and want to know on what basis I should take the decision of caching data.
Q2) I have a huge data set which can change frequently. On my app I am showing the data under different categories and is planning to fetch the data from server when a particular category is tapped. This will reduce the data transfer. Also, this data can change frequently but I can store it for let say 30 minutes. What strategy should I take here? Should I store in core data or no caching all together and for each repetitive taps should hit the server?
Please suggest.
What does "hit" mean in this context? Asking the server whether your data is fresh or simply refetching it?
I would suggest that you cache a few MB or so, that you assume that data stays fresh for at least thirty seconds or so (depends on your scenario). If you want the application to feel very fluent, download everything that can be reached with two taps (or so) or less if it isn't yet cached after each tap (as long as that isn't too much data).
You might also want to include a less-data-mode for users who have a traffic-based-costs internet access.
It totally depends upon the frequency of new data. You can cache the data that's to be displayed at the application launch in all your tabs and then let the updated data flow when user makes request for new data.
Is there a limit to how much persistent storage a single iPhone app may consume?
What does save set the error argument to if the iPhone hits a per-app limit? What if it hits the hardware limit?
Is it possible to limit the number of objects stored for certain entities? If so, what's a good approach to doing this?
acani, an iPhone app I'm working on, downloads the nearest 20 users from the server and saves them to Core Data. After using the app for a while, the users SQLite table could become rather large. How could I limit it? What should I limit it to? Once this table has reached capacity, how could I make it so that newly downloaded users replace the oldest downloaded users?
Thanks!
Matt
I don't know the answer to the limits questions, but I would think you would want the maximum amount of data to be limited well ahead of that. There are some iPhone apps (games0 which take up a large amount of storage (I think Myst is something line 1.5G). But if you allowed your database to grow to those sorts of sizes you might start to impact on the storage the user has for their other applications.
I'd be inclined to suggest that your application needs to have some sort of database house keeping implemented. You will have to write this. Either automatically triggered or manually triggered by the user. For example you might want to setup a settings option where the user can specify how many "old" users it wants to preserve. If users are being added automatically based on location, what sort of algorythm would a user most likely want to cull the list with?
There is a 2GB limit for apps from the App Store but as far as user data goes, you should be able to basically fill the disk. When that happens, your saves will start to fail, I believe with 'NSFileWriteOutOfSpaceError' bubbled up from the PSC.
As far as limiting entity space, there's no Core Data support for this - you'd have to handle it programatically. You could extend the validation system to check for certain conditions (free space, number of entities) and fail an insert or update if these didn't match your criteria.
If you want to delete old users, just sort the results and delete the first/last one.