Hello, I’m going to release my application in beta test with a usage of about 50 people. I’d like to increase this number to 100 within a month. And then to 1000. Will this fit on my application? Is there any way to make it lighter, maybe to avoid a crash? And is the Maker offer enough or does it make no difference? Thanks a lot!
The Maker plan allows for unlimited personal (aka non-corporate) users. As long as it also includes any integrations you may need for this app, it should be a good choice.
If you require any of the integrations or data sources in the Team or Business plan and you do end up with 1000 users, your best bet is to contact the Sales team about an Enterprise plan.
1 Like
But in terms of speed, servers, … it doesn’t change anything?
If you’re using Glide Tables, they have incredible performance even with very large data sets. 1000 rows or users should not be an issue.
1 Like
Millions of users are using millions of apps on those same servers. One more app in the mix isn’t going to make or break it.
1 Like
No, it’s just that with all the stuff I’ve already got on my app, it’s already a bit slow to launch, so I was wondering if there was any way to make it run more smoothly.
Individual app speed really comes down to how much data needs to be downloaded, how many computations need to occur once the data is downloaded, and how much needs to be rendered on the screen. There really isn’t a good answer for that. It just takes a lot of trial and error to make things efficient. I still struggle with speed for certain parts of my app even though I’ve made several improvements over the years to make it more efficient, but at the same time it’s processing several thousand rows of data and creating links between several tables. At that point it’s more about the processing that you make happen on the end user’s device and less about what the Glide servers are doing.
Be mindful that all data is sent to the user’s device and most computations happen on the end user’s device. At most, all the server is doing is syncing raw data back and forth.
If I have any one piece of advice…try to avoid relations that rely on computed columns, because that essentially requires the data to process twice. Once to do the initial computations, and a second time to establish the relations. Also, it would require all data to process at once instead of as needed to display on the screen. Same for filters too. Anything that relies on computed columns is going to require a lot more initial processing and can compound depending on what you are doing. If you can try to reduce the reliance on computed columns in large tables, then I think you will see a noticeable improvement.
3 Likes
Similar to Jeff’s reply:
Amount of data
• How much data is loading on the primary tab. In the app in general. On-screen.
• How many different collections and hidden collections with visibility conditions on any given screen.
Computed columns & Relations
• How many and how complex are computed columns
• Are there (too) many relations that link to other tables
• Avoid relations that rely on computed columns (compounding computations)
• Avoid filters that rely on computed columns
Images
• How many images on-screen
• How large are the images (even though Glide should optimize for this)
2 Likes