I’m currently rebuilding the app that I’ve been using for my personal business for almost two years because it was the first app I created and figured it would be better to rebuild it completely rather than fix the original one.
My current problem:
App has 24000 used rows and running really slow, constantly crashing for every user.
I built actions to delete multiple rows monthly to free up rows
Only uses glide regular tables, no big tables
Lots of computed columns to do workarounds
Messy data structure
I want to build a better and faster version of my app and liked the fact that everything was in one place but I was wondering if having one big app would run worse than having multiple smaller apps using the same linked tables? What is considered best practices in the app development world, one or multiple apps?
I went through the same thing a couple of years ago. The original App that I built for our company ended up being a “Super-App” that did anything and everything. It eventually bogged down to the point where it became almost unusable.
So I progressively rebuilt the the entire thing and in the process split it up into multiple Apps. This is an ongoing process, but right now I have 5 distinct Apps all sharing the same data source.
The Apps work much better than the original, and are much easier to manage. So my advice would be yeah, split it up.
Do you think it runs faster because it is split up in multiple apps or because of the way you rebuilt it?
It feels like having a better structure, using big tables, optimizing use of computed columns and components would be enough to have a big super app running smoothly but maybe I’m wrong. At the end of the day all the apps must load the same databases so it makes me wonder.
Also what if the users must run multiple of these apps at the same time? For example if a user has 3/5 apps open at the same time, it must load 3x the same database so it stresses the device even more?
Mostly related to the growth of the App. The original App was created back in early 2021 when Google Sheets was the only option. There were no native tables, and certainly no Glide Big Tables. So as the row count approached and exceeded 25k it just started bogging down.
No, it’s a shared data source. So all 5 Apps share the same Google Spreadsheet plus a number of native tables. I’ve been progressively getting rid of Google Sheets where I can and replacing them with (shared) native tables and Big Tables. Right now, it’s probably about 60% native tables and 40% Google Sheets. My ultimate goal is to convert to 100% native tables.
I would say both.
The original data source was Google Sheets. Not all Apps need to access all sheets, so splitting them up helped to distribute the row count. Moving some sheets to Glide Tables also helped, as did moving some of the sheets with larger row counts to Big Tables. And of course, I’d learned quite a bit since the original build, so the rebuilt Apps were more efficiently constructed.
Perhaps, but I’ve not noticed any issues due to that. Each of my 5 Apps is targeted at a specific functional group - Operations, HR, Management, etc - so most users only ever use 1 or 2 of the 5 Apps.
No, but I don’t really care about that so I haven’t paid attention. Our plan comes with unlimited storage. But yes, I’ve seen Jeff’s comments about that.
My current rule of thumb is that if I expect a table to grow by 10k rows or more per year, then I’ll use a Big Table. Column count isn’t a factor that I consider. If I had tables with hundreds or thousands of columns I might - but I don’t
