I see developers creating open-ended data apps, like social media, messaging apps. What puzzles me is that when the app is used by thousands of users, the data alone would break 25,000 records. What then? You can’t remove/archive data to save on storage.
Consider 1000 users posting 5 records per month. In 5 months, the app will have over 25k records.
In view of this restriction, I find Glide apps only good for internal, mid-size data uses. Am I understanding this correctly?
So the limit of 25K rows is not actually a brick wall!
You can go beyond that! Just that your loading time may increase a bit!
So yes! Its possible to create open-ended data apps but its not recommended.
Once AirTable or any other large database comes into picture, this may be easier to achieve.
The problem source is how Glide handles data, it’s not a classic Client–server model.
Glide needs to use/read its internal databases (base on Firebase) and no matter what external “database” we try to use (GS, Excel, MySQL, etc), any updated or new row (or value) must be replicated to Glide database in order to be loaded and used on our APPs.
Our data can be saved on our MySQL server but the data on our devices come from Glide databases ruled by Firebase and it’s a bottleneck unfortunately, the synchronization between both sources consumes time and resources.
On small/mid-size APPs, load all data can be a good idea but on large ones the performance and manipulation problems appear as we know. Use Pagination to load data dynamically will be the missing piece that Glide needs to implement.
Meanwhile, use a workaround like bellow to get data frequently without loading it might be an option;
So baiscally the pagination is what i achieved! Yes! Improvements are needed! Will share by EOD IST!
So basically I had to recreate all the functions of add, update and delete using button and sql queries so that a large database is accessible and usable