Data is processed in the scenario in under 1 second including the HTTP request returning status 200 in that time.
Then on random occasions, for reasons that don’t seem network related, the data update isn’t reflected in the Glide Table for another 60 seconds or more.
These kinds of delays really kind of blow out the operation. I’m making good use of the cool new timers that can return messages and set some appropriate conditional notifications pre and post-triggering the webhook. But the experience sort of makes the whole operation pointless if the user needs to wait so long. The data returned is only 3 columns worth (no idea if that really matters).
This has been a bit of an intermittent issue recently, and I’m aware that Glide Engineering are working behind the scenes to address the problem. I think the best advice I can give for now is to try and be patient - it will improve.
I guess I’d also like to learn about what to expect so I can best set the timers. Also just to better understand how Glide Tables work in general.
How does the app on a users device relate to a Glide Table as opposed to its relation to a Google Sheet. I built a bunch of apps on GS in previous years and understood the whole background refreshing and what-not, but I would like to know more about how a GT is linked to an app on a device.
Should an API update (when working properly) be near instantaneously reflected in the GT? (what actually happens in-between me watching the make.com module executing the HTTP request and the GT being updated ?)
What occurs between the GT update and then the data being presented on a user device? (I’d love to have a detailed understanding of this).
If the reflection on a user device also depends on the device’s network connection, if the devices were on the same network (any other user variables worth learning about?) would the user experience be synchronous? So the reflections of the GT update occur simultaneously across devices?
If there are any sources that delve deeper into this or anything that can be shared that helps my understanding of it all is appreciated!
Not instantaneously, but generally within a second or two.
When you post to the Glide API, your request is sent to the Glide backend. I don’t have any technical details of that, but I expect it’s some sort of load balanced cloud based server farm. Once the request is processed in the back end, it’s then synchronised with client devices. In my experience, that usually takes a second or two.
No, I don’t believe that would make any difference because there is no direct client to client communication. Each client would receive its own updates from the back end independently of all other clients.
No, I don’t believe that would make any difference because there is no direct client to client communication. Each client would receive its own updates from the back end independently of all other clients.
Is that because it is sent from the GT serially to devices? How does it actually synchronise with a device? Does the Glide App have to ask for it? Does the GT broadcast it? What’s the mechanism there?
You might be able to tell I don’t even know what the right questions are
Most of what I say here are semi-educated guesses, so please don’t take as gospel.
But I think I’d be fairly confident in saying that clients will request updates from the backend (or perhaps subscribe to updates), rather than the backend pushing them out to specific clients.
If you open a Glide App in Chrome, enable Dev Tools and watch the network traffic, you will see regular requests going to Google Firestore. This is I believe, the client fetching updates.
