🌪 Use Multiple Choice Components to Filter an Inline List

am I the only one to start deactivating any such filters with the new update limit/pricing model?
multiple choice filters could be very costly on updates in an app, true?

I’m afraid that’s not correct. If your filtering technique involves making edits to User Specific Columns, then those edits are counted as changes.

Some of us have quite strong views about this, which have been expressed elsewhere. So I won’t repeat them here.

Although I don’t know what Glide’s plans are here, my gut feeling is that as we see further changes and improvements rolled out, this will in time become a non-issue. One thing to keep in mind is that Glide are not in the business of ripping their users off. If it turns out that this becomes a huge issue, I’m sure they will make adjustments.

But at least for now, @rayo is correct.

4 Likes

thats if you use the Glide’s built in filter.
But if you build custom filters based on choice components. I assume every time you change your choice you will be editing the data field that holds the value of that choice and hence it will count as 1 update. (I think, but i hope not …)

i completely agree with what you said. I’m sure Glide will try to provide the best service for its customers… and i really hope they make adjustments. The Updates is really a big scare for many i assume… You sleep with a $99/mon plan knowing that it could become become $249 the next day but then you wake up to find out that most likely you have to go with a $1000/mo plan.

I’m not saying Glide could not be worth that much for our business and many others. Its just the speed you need to take actions and that fact that you go with the new plan ONLY to sort out the updates issue, whilst many other questions remain unanswered …

scary times and worst of all, co workers or managers will start to ask you to look at other solutions which deep inside you don’t want to replace Glide for.

2 Likes

deleted

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?

3 Likes

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…

Hey, Robert!

How many more updates are we talking about here?

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.

12 Likes

I’ll shoot you a DM to discuss further

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

4 Likes

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 :flushed:

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

Saludos!

5 Likes

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.

6 Likes

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

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.

2 Likes

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.

6 Likes