Hi Gliders. A couple of strategy questions for experienced developers.
(A) Old style glide apps.
Q1: How long will they be supported for?
Q2: There was talk of “a better tool” for converting from old to new style apps. What the latest on this please?
(B) Use of Glide tables instead of Google sheets
Q1: Do you agree with the following. The best strategy seems to be to use external data eg Google sheets for static/non-computed data (+ easy to back-up), and to use Glide tables for computational data items and for data tables that are small/unlikely to change much. Reached this conclusion because Glide tables are difficult to update manually.
In the beginning of 2023 it was suggested that classic apps would be sunset by end of year. Haven’t heard anything official since then… if I had to guess we have a while longer.
Haven’t heard anything on this but I think it ties into your first question… in my opinion it’s unlikely classic apps will be sunset until this new “conversion tool” is ready for use.
This is a good approach… or at least how I do it . If a tables data isn’t mission critical for backup, you should indeed make the entire table a native glide table. A business or enterprise account would open up another option to use the api + query
They are actually no longer supported. They still work, but you can’t get any support for one if it breaks.
I wouldn’t hold my breath on this one. I find it had to imagine how you could get a clean conversion for anything other than a bog standard Classic App with zero customisation. Even if Glide do come out with a conversion tool, you’ll probably end up rebuilding large chunks of the UI anyway.
Disagree. I always use Native Glide Tables as a first choice. The only time I will use an external data source such as Google Sheets is if:
I need multiple roles per user (not possible with native tables), in which case I use a single Google Sheet just for my User Profile table
There is stuff that needs to be done - usually some external integration - that isn’t possible with native tables. This happens very rarely these days.
I’m forced to by a client.
You can import/export data from native tables as CSV, and there is an API.
thanks Darren, much appreciated.
I’m hugely nervous about switching to Glide tables. If there’s one thing I’ve learned about Glide its that you often don’t find out important stuff until you’re way down the development path. Especially nervous in losing the benefit Google sheets has, in being able to ringfence data from Glide rules.
Final thought. I run a sports league and have 4 apps running off the same core data. One for players, one for admin, one for team captains and one for registration. They all do very different things. Means the data and the apps are interrelated. Any development has to be carefully orchestrated. Is this the right approach in your view?
Thanks again
Yeah, that’s fine and I totally get that.
I was the same for a long time. I used Google Sheets and Apps Script for many years before I found Glide, so it took quite a while before I was comfortable enough with Native Tables to take the plunge. But there’s absolutely nothing wrong with sticking with Google Sheets if you’re more comfortable with them.
Yes, no, maybe
Given the choice between separate related Apps and one big Mega-App, I generally prefer the former. One of the first Apps I built with Glide turned into a Mega-App, and became a nightmare to maintain and manage. It’s now evolved into 6 separate Apps all sharing the same Data Source. Much easier to maintain.
thanks Eric ! I wish there was some clarity on this!
I will have to rewrite 4 apps, looking at several hundred hours redevelopment time, for zero benefit. God knows what else is coming down the tracks that means more work when I’ve done that .
. If a tables data isn’t mission critical for backup, you should indeed make the entire table a native glide table. A business or enterprise account would open up another option to use the api + query
.