🌪 Use Multiple Choice Components to Filter an Inline List

[Rosewebstudio]

deleted

[Robert_Petitto]

Hm. Ya, one of my clients went WAY over the update limit because the app has several screens with this type of filter. All write to user specific columns, but USCs still count as edits.

@DJP … we once discussed the possibility to ignore edits that write to USCs. Is this still on the table?

[rayo]

its is going to be very challenging to avoid going way over the limit. No more customized edit screens, no more multiple choice filtering, the floating buttons which switch list layouts or update tab design…

[DJP]

Hey, Robert!

How many more updates are we talking about here?

[Robert_Petitto]

Thousands. I can’t speak on behalf of every developer, but a good number of us use user specific columnS simply for navigation and UI (eg. Write “true” to a USC which shows or hides a component).

With this use case, our intention is not to “update” data records…so using a USC in a way that counts it as an “update” is going to severely hamstring creativity, UX, etc.

[DJP]

I’ll shoot you a DM to discuss further

[Jeff_Hager]

I’d still like to throw this out there as a viable option if possible.

Session Variable Column

I’ve always thought that it’s really useful how user specific columns only store values locally and for the duration of your session while you are not signed in. This allows for those column values to “reset” after you close the app, and the data does not need to be sent and synchronized with glide servers. However, once you sign in, then those values are sent to, and stored, on Glide’s servers. I think a new Session column type could be really useful. It would work just like user specific c…

[gvalero]

As @Robert_petitto says, count every write to USC as an edit is a nightmare and real concern.
Some cases are worse than others but when we use USC to create a better UX, the situation is complex to avoid too many edits.

See this example, I have 2 floating buttons to help user to select any quantity of a product. If a user pressed 6 times the “+” button, my edits count is 6 quickly and if he does the same with other 10 products, my count will be 60 and the process hasn’t finished yet (he still needs to complete the checkout!).

If my APP carries out 20 orders daily (average), it will hit any count edit limit very soon … it’s a nightmare

The Jeff’s idea would be a great solution so far.

Saludos!

[Darren_Murphy]

@Robert_Petitto

Thousands. I can’t speak on behalf of every developer, but a good number of us use user specific columnS simply for navigation and UI (eg. Write “true” to a USC which shows or hides a component).

With this use case, our intention is not to “update” data records…so using a USC in a way that counts it as an “update” is going to severely hamstring creativity, UX, etc.

Exactly. 100 times over.

@DJP I just looked at my usage dashboard. I see 52k edits and only 1.2k adds. My conservative estimate would be that 50 of those 52k edits are the types of “edits” that Bob describes above. That is, they are not changing any actual data. Instead, they are used to enhance the user experience.

[sgh]

Hi there,

Just started evaluating Glide. If I use the built-in Glide tables does the update problem apply or is this only an issue for external sources?

TIA

[ThinhDinh]

It still applies as of now because it’s viewed as an “edit”. External sources consume “edits”, plus “syncs”.

[sgh]

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.

[gvalero]

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.

[nathanaelb]

@sgh

The whole charging per update is ridiculous especially on their own Glide tables.

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.

[Darren_Murphy]

@sgh

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.

The below from Glide’s CEO might help to understand:

All-New Team Plans Coming Thursday, April 21st

This pricing was entirely our invention, and did not come from outside. The #1 thing that drives our costs is data updates. We have two options to make our business work: Charge per app user Charge for app use #1 is just a proxy for #2, and was extremely unpopular when we tested it (e.g. pay $2/month for every user of your app). We want Glide to work as a long-term business, so at the very least, our pricing model needs to reflect our costs. Today we have many apps that cost us hundreds …

[david]

@sgh

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.

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.

[Luther]

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

Use Multiple Choice Components to Filter an Inline List

Hm. Ya, one of my clients went WAY over the update limit because the app has several screens with this type of filter. All write to user specific columns, but USCs still count as edits. @DJP … we once discussed the possibility to ignore edits that write to USCs. Is this still on the table?

[rayo]

we could still use multiple choice filters inside edit forms with no updates counted … right?

[Jeff_Hager]

Correct. Add, Edit, and Form screens do not write any data until the form is submitted.

[resepsionis_ganteng]

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.