Curious about one thing. Are Pages structured similar to Apps where the full database is cached locally and any actions against the data happens on the local copy before being synced to the serverā¦or do Glide Pages have more of a server driven database where data changes are posted back to the server and processed on the back end. Just trying to get a better understanding of how to handle situations with multiple users touching the same data at the same time.
For example if two user change data in an app, usually the last change wins, or a user will see old data if a change from another user hasnāt synced to all other userās cached copy yet, before they start working with the data. As a web developer, Iām familiar with server driven databases and postbacks and how the server handles the backend processing rather than the frontend. I just wasnāt sure if Pages follows more of that approach, or if itās moreso similar to the current approach thatās used for apps.
Glide pages currently operate almost identically to Glide apps. That said they internally are a massive overhaul in how the frontend and backend communicate (that being that they communicate via a very strict interface). This strictness is to enable some of the things I am sure you are curious about.
This looks very interesting, I did my 20-year sentence in the corporate world and donāt plan on going back. But my suggestion regarding apps/spreadsheets would be to create a āproject bundleā that might involve 2 apps, 1 or more spreadsheets, and Glide tables that could interact together. Right now it appears that if you built 2 apps from the same spreadsheet, they would not be able to share the benefits of the same Glide tables, which could mean a lot of duplicated work. By paying for a project bundle, this also might give more flexibility with pricing.
IMHO I would have assumed the feature could be offered at no extra cost with a pro-App subscription. I rarely need to upgrade from Basic to pro and this would have helped boost the value proposition.
If I already paying Pro for the app & want to add pages using same data, Iād be ok with like 15-20% above base app license? That just off the top of my head.
Not sure if unlimited use would work for Glide but a tiered system
We have a similar issue with our platform as we continue to build and add more features, we have to keep changing the pricing model.
I think the pricing model will continue to change and refine, a balance between monetizing new valuable features that had significant value and then not making to expensive, you may need to charge for features initially at launch and then include them (FREE) in standard package in the future when you have other new great features to add, otherwise it will get expensive and complicated (this sometimes results in temp. loss of revenue when you stop charging for features ā hard call to make when you need the money). A tiered system may helpā¦
Some pricing thoughtsā¦
e.g first 10 apps at $x each
and then next 20 at $x - y%
next 30 at $x - z%
ā¦ and so on
Standard app = $x ($35)
Glide Page app = $y
both apps looking at same sheets = $x + 25%
But my suggestion regarding apps/spreadsheets would be to create a āproject bundleā that might involve 2 apps, 1 or more spreadsheets, and Glide tables that could interact together. Right now it appears that if you built 2 apps from the same spreadsheet, they would not be able to share the benefits of the same Glide tables, which could mean a lot of duplicated work. By paying for a project bundle, this also might give more flexibility with pricing.
