It still applies as of now because itâs viewed as an âeditâ. External sources consume âeditsâ, plus âsyncsâ.
Thanks. The whole charging per update is ridiculous especially on their own Glide tables. I can sort of see the sync part to external sources but âinternalâ updates? WTF. No other word for it than a very bizarre business model where you punish your users for using your products most basic feature.
Shame but I really canât take this as a serious product for deployment - so thanks for the quick response - so I can stop wasting my time. Bizarro.
The whole charging per update is ridiculous especially on their own Glide tables. I can sort of see the sync part to external sources but âinternalâ updates? WTF. No other word for it than a very bizarre business model where you punish your users for using your products most basic feature.
I have no way to disagree with this. Counting any write to USC as an edit makes no sense to me and makes it hard to create smart and customized solutions.
I hope and think that Glide team is thinking in a workaround for this situation soon.
Shame but I really canât take this as a serious product for deployment
Donât go so far, Glide is improving every 3-4 months and some mid-complex deployments can be developed easily in next months.
I know nothing about Glideâs cost structure. If I had to guess though, I would say one of the variable costs of Glide directly related to the product/tech is the amount of computation that happens across the projects of Glide developers. Glide probably runs its own servers, maybe uses AWS or things like that, and the cost of a gazillion bits computed in a project is higher than if only a few bits are computed. This assumption could be wrong, correct or somewhere in between. Gideâs pricing in part based on syncs and edits would then simply reflect this, the cost of computing data. So until Glide is big enough, it does not shock me that Glide passes on some of its technical costs onto the customer.
The below from Glideâs CEO might help to understand:
Glide is built on top of Google Cloud, where we pay for each time we create, edit, or delete your appâs data. Do you think Google is âpunishingâ us for using their cloud?
We donât view Google as punishing usâthatâs just their business model, and itâs ours too. Maybe you think that editing data in Glide Tables is free for us to do, so it should be free for you? It is not free.
We expect you to pay for Glide if you use it seriously, and the more you use it, the more you should payâit definitely costs us more when you use Glide more! If this seems like a ridiculous idea to you, then I donât know what to tell youâitâs how most businesses on the internet that arenât driven by ad revenue work.
Hi @david,
May I kindly ask that you also address the question or uncertainty around the use of USC and why they are counted towards updatesâŠ
This is a real concern not only for @Robert_Petitto but for many and it was highlighted a couple of times in the thread about the new plansâŠ
Are there still talks around it and if so, when can we expect some form of feedback. Before it was not much of an issue because quotas were not enforced but I think now Glide is at a stage of enforcing quotas. I hope we can have a general response or commitment to this rather than User specific solution (Pardon the pun) âInbox me type of solutionâ. Thanks
we could still use multiple choice filters inside edit forms with no updates counted ⊠right?
Correct. Add, Edit, and Form screens do not write any data until the form is submitted.
As expected, Glide uses Google Cloud like firebase or indeed firebase. I also see storage and change billing in Firebase or Firestore.
I think the way Glide works is like this.
Glide uses React and Styled-components as frameworks and PubSubJS, HowlerJS and core-js as their JavaScript libraries and largest storage Google Cloud.
Glide doesnât make apps without code for free but wants to build a large and mutually beneficial community.
Iâm honestly very happy with Glide, even custom CSS and HTML are not available on other no-code Appbuilder platforms.
Simple genial, genial simple! Congratulations!
Nevertheless I have one caveat: mltiple choice can be done substantially more simple!
Instead splitting entries separated by commas, you can use INCLUDES!
Multiple choice filter âAL,FLâ includes both AL and FL records!
While that is true, you need to be careful. If your choices could include AL, AAL, FL, FFL and a user chose AAL and FFL, then the include would be picking up the wrong rows. Not only the rows with AAL and FFL, but also the rows with AL and FL because AL is included in AAL. You just need to make sure that none of the choices have similar characters.
Of course, I am aware of that. I am using that in my app for recording and presenting children injuries for the column âInjury circumstanceâ, such as fall, drawning, hit by object, traffic etc. In such case there is no risk of such mistake.
Another topic: is Glide aware of one funny bug in multiple choice? It doesnât function when entries end with the space!?
in addition, thie problem can be mitigated very easy: if you have âAL,AAL,FL,FFLâ (there are no spaces after commas!), you can convert this in â,AL,AAL,FL,FFL,â and also to search it not with original entry âALâ, but with â,AL,â instead! Here you have in theory the jeopardy if you have real commas in your data, but I think this is negligeable!
Yeah, Iâm sure they are aware. Iâve seen glide suggest that people should check for spaces, so Im not sure if they view it as a bug or not.
âworks as designedâ!
This is defitively the bug!
Hi, Robert. Thank you for this tutorial.
Iâve watched the last version and I loved it. Itâs a simpler and more elegant solution than showing and hiding a lot of inline lists. It really helped me simplified my app. Thank you very much!
Now, I was having second thoughts about what you say in the video at 2:55 - filtering the screen with âEmail is signed in userâ -, so I tried not to, and it works fine.
Please help me if Iâm wrong here: since the choice is stored in a user-specific column in the Users table, it only affects the signed-in user, not the other signed-in users, nor the not-signed-in users.
Something really important is that if you put the specific user colum for the selected choice in the Users table, only the signed-in users will see the choice component. The anonymous users wonât be affected by the filter, and even more: they wonât see it, the component does not display in the screen.
In my case, that resulted positive, because now the filter is a âfeature for membersâ, but for others maybe it can be an inconvenience.
So, when you want every user to have this filter functionality, you have to store the specific user column for the selected choice in your data table, and not in the Users table. I think in that case your saying in the video is right: then you do have to filter the screen with âEmail is signed-in userâ or else your choice will affect to every user in the app.
Can you please take a look and tell me if Iâm right or wrong? Thank you in advance
Youâre right. This is assuming that your users are signed in to the app. If you donât have signed in users, youâd have to create a working table, use user specific columns, and then bring in those values using single value columns rather than a template column.
That was fast!
Yes, I was making it that way with my old filter for everyone. Thank you again!
All this is amazing, but can this apply to the Website format? (not app).
I cannot even make it work for a single filterâŠ