Nice to see another Glide app working on Wine - congratulations! This is not to answer your post, but I would sure appreciate some traffic to my wine tasting app called Swirl. Any tips on how you are doing so well?
You may want to consider a slight restructure where you place all of the cellar id’s/names into a delimited list in the user record. Then you can use a Split Text column to split that list into an array and use it to create a relation to the Cellars sheet. That way you aren’t writing a bunch of rows for each user. It would just be a user sheet and a cellar sheet.
Another thought is a user specific column in the Cellar sheet, such as a boolean column (or favorites). Then a user can filter the list based on that user specific column and you still avoid writing a bunch of rows for selected cellars. Rereading though, user specific columns may not work well if you are using it to connect to other users, but it could still be part of the logic to build the delimited list via a Joined List column.
@Rogelio Congratulations on your success with the wine app your created. Please keep us posted on how you overcome the growth challenges that you are experiencing and how Glide has supported that growth for you. I know database capacities have been a big concern for users for many months. So curious to see how this all pans out. Best of luck to you.
Congratulations @Rogelio on your new traffic. I’ll be following this thread as well and hope the Glide team and other helpful members can help you scale your success further.
@Jeff_Hager - Noob question but can your suggestions to Rogelio be utilized in apps based purely on Glide tables as well? I know many in the community like to have Google sheets in addition to Glide tables but I was told by support that building on top of tables helps ensure the speed of our apps are optimized by avoiding a bunch of data atomicity related headaches. Thanks
if you think round trip
— user enters something on their device, it gets updated on the server (GT/GS), data gets pushed to, say, another user
GS only = 20-45 seconds (assuming GS is not actively used)
GS-computed columns = 10-15 ish (I’m trying to remember, can be longer)
GS-usc columns = 2-5 seconds (but then you might need to wait for the impact of the usc to ripple through)
GT = 15-25 seconds round trip as above for my double-app using a shared GT)
On device changes - almost instantaneous if the elements you need are computed…. But with visibility things it might take 0.2-1 sec (which means screen flash)
some computed columns cause more issues with updating than others - especially time
Now I have designed a high volume call center app for telemedicine. This is not your typical Glide use case!!
As I understand his problem and imagine the solution, my suggestion would use purely glide computed column functionality, so there would be no need to use any google formulas or scripting to accomplish any of it. Because of that it would make no difference if an app is Glide Table or Google Sheet based.
As for speed, I haven’t sat and timed anything real extensively. My primary app is over 2 years old and was built prior to Glide Tables existing. Some parts are slow, but I believe it’s self inflicted due to how many calculations I’m performing, but 95% of the functionality is now using glide computed columns. I would have to believe that Glide Tables have some speed advantages due to the lack of a need for glide to sync with a google sheet, but as I see it, google sheet based apps still have the database duplicated on glide servers as glide tables. Since an app communicates with the database on glide servers I wouldn’t imagine that there would be any major speed issues unless there is a need to resync large sets of data between google and glide, or if you have formulas or scripts exclusively within the google sheet, then there will definitely be lag waiting for data to sync to the google sheet, calculate, then make the return trip to glide before being pushed back out to the app.
Think of it this way…with a google sheet based app, there are up to 3 copies of the data (google sheet, glide db, and local app cache). With a google sheet based app, there is the additional path that data has to travel to sync, but I think it’s mostly only noticeable when the google sheet is doing additional work. The app synchronizes with the glide servers exclusively and the glide servers synchronize with the google sheet, so the app won’t know any different either way. Glide Tables and/or USC columns will only ever reside on Glide servers and the local app cache. The only potential problem I could maybe see with google sheets is if there is heavy data entry or changes that would cause large amounts of data to sync between glide and google often. I still think a sheet based app that primarily uses glide tables would give you the best scalable performance while allowing for the potential to switch to using the google sheet if some of your data needs to access some functionality that’s only available with a google sheet.
@Rogelio I’m imagining something along the lines of how the demo apps in this thread build a joined list, which could be saved to a single row and later split again for any relations. @Roldy has a good example where he actually saves and recalls the saved selections. I’m not sure if it would give you exactly what you need, but if it works, it would potentially eliminate the need for several additional rows. You may still need a separate table, but it would have only one row per user/tour. If possible, you could even place the joined list in the user profile row and eliminate the extra table altogether.