Any Word On These Features Coming in the Near Future? (lazy load, record locking)

[mykrobinson]

Morning, all. Been a while.

I have been on the appsheet platform making a few things for the day job for a couple of years now.  I have zero programming/app dev experience before appsheet so my view of things is often through the lens of a relatively inexperienced citizen developer.

Anyways, the apps i build for the clinic tend to all suffer from the same things, and i have found that switching to SQL instead of Google Sheets does not yield certain performance boosts i was hoping for. Seems the root cause of a lot of slow app loading, at least in my case, is due to the reliance of a lot of virtual columns due to calculations that may change frequently. It seems that appsheet does not support lazy load, so all these virtual columns for EVERY DANG ROW of all databases attached to the app(s) in question are loaded upon initial sync as opposed to on demand, thus contributing to the sluggish load time. Do we have any evidence of devs working towards a lazy load option in appsheet?The workaround of hard coding cells to avoid virtual columns is not always a great solution, unfortunately.

My other ask is regarding intelligent record locking. The sync delay can, with enough users on a given app, lead to an issue of more than one person working in the same record at the same time with no knowledge of someone being in the record in question, and can of course lead to sequential unexpected data overwrites. Is there anything in the works to help prevent users from doing this, or does anyone have any suggestions for workarounds to implement some level of record locking with visual indicators in AppSheet?

Thanks for listening.

[Joseph_Seddik]

1. App Performance

Lazy load is a front-end feature, it is meant to speed up the "display" by showing less content in your browser window/viewport. This is especially useful when your page contains high volume images or dynamic content, so that your browser might consume less memory and processing/gpu power and you get a faster load of your content. 

Lazy load on the other hand does NOT involve calculating/generating content that's occurring on the backend, it is only meant to display less of the already calculated content. In AppSheet context that might be useful I'd say only for format rules, not much more. 

When your problem is coming from sync delay due to virtual columns, lazy load would have nothing to do with that. You have to replace your virtual columns by physical ones. Keep in mind also that in the life of a database record, this record will be updated for few times, then remains with its values unchanged forever. Therefore, you should manage such changes with automation and app formulas that will be triggered upon specific changes. There's no way around that; a developer should keep performance in mind in every step he takes during the development of his app. 

Also, a real database would bring a tangible improvement in performance and sync delay over Google Sheets; because it allows for segmentation and partial loading of data in your app through security filters. If you are not implementing this, then a real database would not bring you benefit per se. 

I highly recommend you to carefully study all sections of this guide, and ask the community in case you face difficulties.

Optimize performance and reliability - AppSheet Help

[mykrobinson]

Good morning, and thank you for the response! I will look over the link you posted, thank you. I know the current state of the primary app i made is not great and it seriously needs a rebuild. I will proudly say that i made the app under duress, in some respects, knowing full well that i am NOT an app dev, so some things were definitely made with workarounds, duct tape, and a little chicken wire.

Given my limited experience, my honest thought is that my employer ultimately needs a software dev firm to truly produce the product that they are wanting. I use AppSheet because of their push towards the product. I feel it is okay to make a prototype to kinda show a software developer a mock up of what we are looking for, but am wondering if there are those out there who are using it in large scale deployments and are truly happy with it.

Again, i openly admit that some of the issues we are having are due to my lack of experience and trying to brute force features ad hoc as one would ask "hey can you add this or that real quick." My sincere hope at this stage is to properly plan and document the ideas well enough to present to a team with enough manpower and experience to devise a true solution for the need(s) or the clinic.

[Joseph_Seddik]

You did a great job and will see it through, don't be discouraged my friend! You just need some reading and a little push from the community. That's all!

[Joseph_Seddik]

2. Concurrent updates

Last update on the same record always wins. There's no way around that; hence, for a large number of users, you should never allow users (or processes) to update the record directly. Also keep in mind that when a single column is updated in a record, all the other columns of the same record get reevaluated and written in the database. So the solution is this:

• Instead of allowing the users to Edit the record, provide them a way to update single columns using actions. You'll find the newly-available INPUT functionality very useful for this purpose.
• These partial column updates should not be written directly in the original table, but they should rather be written to Buffer table. An automation will then be triggered upon new adds in this Buffer table to update the corresponding columns in the original table using the latest version of the database on the server, as opposed to the version on the user's device that at the time of update might have not been synced to the latest version.

[Rifad]

---

@Joseph_Seddik wrote:

You have to replace your virtual columns by physical ones.

---

I have been doing this. But its effects the ‘edit row’ time which cumulatively increase the overall sync time. Again, if the same table have couple of automation that condition is always ‘false’ still it takes time to edit a row.

I had contacted AppSheet regarding this many months back. No much updates. In many cases if to and fro updates are made in same row and lets say 10 updates are in queue (which is normal) it sometimes take 45 sec to update + 12 seconds to sync. Which is insane. These days ai is creating craziness in less than 20 seconds. 

When AppSheet/ google decide to do all these ai advancements. They must solve and adress fundamental issue.

here is the a thread with similar : https://www.googlecloudcommunity.com/gc/AppSheet-Q-A/Row-Editing-is-Extremely-Slow-An-AppSheet-Suppo...

Note: I have considered all the performances in mind while building the app. But its just a large app with all physical coulumns mostly. Some refrows are inevitable and never used SELECT() in 95% of the virtual columns.