Hi guys,
I have been developing my app for the last year and recently, the bigger it got, the more crashes, delays etc started to happen (mostly in the builder - not the app itself)
Today it takes me about 2 min just to load the app and often I get a black screen.
And I am not talkin about the 25K row limit which is an issue I will have to take care of in the near future, I mean the structure itself.
I have about 50 table - most are GS.
My Users table has over 150 columns (about 50 GS and 100 Glide columns)
I have 5 more large tables with over 100 columns and the rest are in average about 30 columns.
I have 2 roles that show completely different screens
20 tabs and hundreds of compound auctions and dozens of screens.
should I be concerned?
did anyone ever get his app “too big” for Glide?
Caveat: Please take everything I say here with a grain of salt. I’m only speaking from my own experience, and bits of information that I’ve been able to glean from various other folks.
Yes, I believe there is a hard limit on the size of an app. As you suggest, it has nothing to do with row count, but is more a function of how complex the app is and how much file space it occupies once it’s all bundled up.
I have an app that’s been skirting the limit for a while now. A month or so ago, I split a whole bunch of functionality out into a separate app, to reduce the app footprint and buy myself some time. I’m now approaching the limit again, so I’m most likely going to have to go through another round of that very soon.
Just by way of comparison, my app currently has:
50 Google Sheets
~40 Glide Tables
22k rows
~2000 computed columns
~100 screens
Based on your description, I wouldn’t be surprised if your app is approaching the limit. But, please don’t take my word for it. I’m only speculating based on my own experience.
My advice would be to contact Glide Support - they are the ones to advise on this.
I do recall reading somewhere (maybe a comment from David) that Glide are working to remove or extend this limit. I have no idea if thats true, but I hope so
No, not data. The size of the app itself (bytes) excluding any data or external resources.
What I did to reduce the size was to remove a bunch of tables and associated computed columns and screens, and rebuilt all that in a separate app.
But again, I need to stress that I do not know this for a fact. I don’t know what the actual limit is, and I don’t know exactly what contributes to the limit.
As I said, the best thing to do is contact Glide Support about this.
My latest experience that has brought benefits in terms of overall performance of the APP was to minimize the use of relations between GT tables and GS tables especially when used to search for data which is then used as the basis for a computed column. Or, even worse, for creating a new relation.
This completely solved the ghost lines issue I reported a few months ago
and nowadays, I reduce relations as much as possible between GTs data as well.
In other words, when possible, I replicate data in multiple tables instead of accessing them by relations.
From my point of view, this fully confirms @Darren_Murphy 's thesis, which is that the problem is not the amount of static data contained in the tables.
Hi, I have an app composed of ONLY GS tables + one table that is a working table in Glide. Rows are deleted from the working table after data is validated and added to one of the GS tables. Therefore it never has more than a few rows in it. But I have seen that which you speak of – when I delete some of the rows from my GS tables, they keep coming back again and again, and I have to delete them again (using the app delete function). If I delete them in the Glide data editor or in Google Sheets, they are gone for good. It started happening when I had to re-create a custom function several times because I kept changing my mind on which object to tie the custom function to (and you cannot re-use custom functions yet). I thought perhaps Glide was keeping the defunct custom functions active in the background and that’s why I was seeing multiple duplicated rows. Have not been able to reliably reproduce it, but it’s still happening in that app from time to time.
If you mean using the delete action, then that is not the most reliable one. I have seen @Darren_Murphy complaining about that more than once, maybe using an approach of setting a flag (like true) then using script to delete the row is more reliable.
Yes, that is what I was referring to, and I have had no problems with it in a Glide-only scenario – only when using mixed tables, and specifically Google Sheets…
I’m experiencing the same thing and it’s so frustrating.
I have ~50 GS tables, ~20K rows, a lot of computed columns and it’s very slow when my members use the app on mobile phone.
So I’m wondering if it’s better to use Glide Pages instead?
or maybe change for Softr for example?
