Hi! My last question for this week!
Would Glide consider enabling SSO between Glide apps ?
I’d like to organize some apps as “modules”, and interconnect them as needed (even conditionnally).
Ex : 1 Main/Mother app + several “satellites/Children” apps. They all belong to the same set/family. An app made of several small apps.
Advantages : smaller apps, smaller & simpler tables, Glide limits very far from reaching ;-), flexible, easy to maintain (by different, separate teams if need be)
But, for the end-user, it should be seamless, with only 1 Sign-in, and centralised User Profile (or at least, I can copy each update in all apps to mimic synchronisation) and keep calling my user on First name basis.
Is it sth that could fit in Glide’s mindset?
Thks!
You could share the profiles table, or even to an importrange between your different sheets to share profile information between tabs. Users would still need to sign in to each, though, but would have a unique profile.
Thks but how can you share a Glide Table (as it’s a Glide and not Google Sheet table) ?
And even though it’s a Sheets table, is it possible to share just one Google Sheet Tab ?
Glide tables can be shared across multiple apps. One thing to note that isn’t mentioned in the docs is that only basic columns are shared - not computed columns.
A Glide app can only use a single Google Spreadsheet as a source.
However, multiple Glide apps can use the same Google Spreadsheet as their source.
If you want to include a single sheet from a secondary spreadsheet, the usual way to do this is to make a read only copy of the sheet using the IMPORTRANGE sheet function.
If you have sheets in your Google Spreadsheet that you don’t want to be seen in your app, then as long as your app doesn’t reference those sheets anywhere, then none of that data will be downloaded. See Glide Docs
oho ! I’ll have some work to do… That’s very promising for my app evolution. Thks a lot. I’ll come back on this topic in a few weeks, I think.
So, I can share the User Profiles basic columns that should update on-the-fly as new users come, but I’ll have to recreate and compute all the template columns to get all the firstname-basis customizations where I write everywhere sentences including the first name inside, like actual sentences you tell to someone.
These columns have to be computed anyway, so, makes sense.
Yes, that’s correct.
The key to understanding why it is this way is being aware that all the computations that happen with computed columns take place on each users device.
oh, that’s good news! Like a Client-Server environment, but without any actual “client” to install, which is a huge time-saver for deployment. And no server admin, since nobody can control that Glide part. So no admins, either, only “visibility rights managers”.
Instead, just the PWA that works with the tiniest part of code to load.
Thks. 
um, not really.
In a traditional client-server environment, the client sends a request to the server, the server processes the request, provides a response, and then the client acts on the response.
In a GlideApp, everything happens locally on the client device, and there is (generally) no waiting around for a response from the server. This is one reason why GlideApps (and PWA’s in general) provide a much snappier user experience. There is still syncing going on between the device and the backend in the background of course, but this is mostly transparent to the end user.
There is a downside to all of this, and probably the biggest downside is the potential for race conditions and users bumping into each other. Imagine two users interacting with the same app, and they both decide to update the same value at about the same time - but to two different values. Because the change is initially made local to each device and then later synced back to Glide in the background, it will initially appear to both users that their change was successful. But in reality what happens is that the last one in “wins”. So the first user would initially see the change being applied, and then some short time later - once everything syncs up - they would see their change being reverted.
This is not something that happens all the time, but it can be a problem with heavily used apps where you have many users making lots of updates simultaneously.
I do believe that Glide have plans to deal with this issue in the not too distant future.
Hum. As as former Lotus Notes/Domino system admin/dev/instructor/consultant by Lotus Development France (then IBM, now HCL), since 1995, I know exactly the issue of concurrent edits in asynchronous mode.
But, this is not the case if I add “Add row” in each key action to track users journey.
Because the PWA that used to work (except for swipes - needs to set the “save” column for card last saved status, and any thing requiring to write in tables, so server-based) disconnected, well no longer works.
- You click on the “buttons”, “actions” with “Add row” somewhere, even at the end: Glide read the code entirely instead of stopping at the “Add row” = your full action is NOT executed.
- You can no longer navigate (even click on the 1st floating to enter the app), except via tab icons that you cannot code/track.
- If “Add row” was local (say a “temp table on local”, the action would execute. If ti stops, that means the app needs a connection to Glide server? My Add rows are to Glide Tables, so don’t even depend on Google Sheets, if it happens to be an issue to the connection to Google Server.
- If Glide could run code by respecting the order of execution and return error/exit only on error-basis, the behavior would be more manageable (and optimized, from basic dev POV).