API Calls as a solution to the Filter/Search problem of Big Tables? - Price Issue

Hi there!

Currently Glide asks around $0,01 per update/edite of a row (you can buy 1000 updates for $10). However, when using new API call action to update rows in Glide, this will lead to also $0,01 for each update.

I saw API calls as a solution to some missing functionality in Glide Big Tables. In particular not being able to filter/search on calculated fields. For example if you have a Team Big Table and a Goal Big Table and you connect Goals to Teams through a relationship of the Team’s Row ID, you can still lookup the Name of The Team with a Lookup Column but you can’t filter on that name as it’s calculated.

Instead of creating just a Lookup Column, you can create an extra Text Column and dump the Name of the Team in the Lookup Column every time you create or edit a Goal. This way you can use the Filter/Search like with a normal Glide Table on the Team’s name.
However there’s one issue. What if you edit the name of the team? The dump in the text field will not be updated automatically.
In this case you can add an action that every time if you change the name of a Team, you do an Api Call and change name in the associated Goal’s Text Column.

This would work perfectly in a technical way, however given that it’s $0,01 per update, you will soon become bankrupt as one Team edit can lead to hundreds of edits on Goals.

The result is that it becomes best practice to build relations on ‘Names’ rather than on ‘Row ID’s’ with Big Tables if you still want to be able to filter or search on the name. Changing names in this case leads to losing relations which is not that user friendly of course.

Any thoughts on this?

Nathan

You don’t need to use Call API for this – you could just set the column value in the action (which may also use an update anyway).

How many times do you think this action would run each day in your app? Our plans include thousands of updates–unless this is happening hundreds of times per day, I doubt you would even notice, let along go bankrupt.

I don’t think that would work in this case, because presumably there would be several rows that need updating. And it’s not possible to do a Set Column Values through a multi-relation/query… :man_shrugging:

3 Likes

@david @Darren_Murphy

How awesome of you two to join the chat! (It’s an honor to have you David)
I made a wrong assumption. Let me give an example. (If you don’t have time, the conclusion is in fat at the bottom of this post but I think it’s harder to understand without the example)

Let’s say you have a project with two Big Tables:

1. A supplier Big Table → A supplier can have multiple Products

2. A Product Big Table → A product can be associated with one Supplier

I know that you can log calculated fields of big tables in simple text fields with the ‘Set Column’ action every time you create or update an item in a table. This is very useful as it still allows you to search, group and filter by a culculated field through that log field! I did this by logging the calculated 'Supplier Name" lookup column in the ‘Name Text Log’ Field in the Product table as you can see below.

The problem however with the above is that when the name of your Supplier changes, the Name Text Log field in the Product’s table will still show the old Name (while the Lookup field will change, which is irrelevant because we unfortunately cannot use to filter/sort/group) so filtering, sorting and grouping will happen on the old name.

My goal thus was to also change the ‘Name Text Log’ Column in the Products table, whenever the associated Supplier name was changed. I thought I could do this with an API call to the Products Table (with for every associated Product one mutation) whenever the Supplier’s name was edited. This would become expensive because if a Supplier has 300 associated products for example, you would pay $3 for one edit (You can buy edits for $10 for 1000 edits or $0,01 per edit).

To be able to create such an API Call and add it to an action, you would have to create a Template Column with the Body of the Api Call with for every associated Product one mutation. You can construct that mutation with a template column in the Product Table. I did this in the example with the ‘JSON Update Element’ see below:

However, to join the mutations into one JSON Array. You would have to create a Query Column in the Supplier Table which finds all associated Products. And then create a Joined List of the ‘JSON Update Element’ column of the associated Products.

However creating Joined Lists on calculated columns in Big Tables is not possible so you can’t possibly create an Api Call that changes a column value in all associated rows.

Therefore my remark becomse rather hypothetic and consists of two rather than 1 remarks:

1 - updating the Simple Fields in an associated rows in another Big Table (in order to use in filters/groupings/searches) when an entry in the current table changes in bulk is not possible. That’s a pity and changing that would be awesome.
2 - Secondly, if 1 would become possible. The current pricing of Glide wouldn’t work as 1 requires a massive amount of updates.

Finally, if 1 and 2 were to be changed. Big Tables would have almost the same functionality as Normal Tables (apart from the loading times of course) which would be massive in terms of app reusability. Instead of constantly copying my apps (with Templates), I would just be able to make every app with Big Table and onboard new customers on one and the same app. Meaning that any update I do in the app, I have to do only one time.

Finally 2: another and maybe even better solution to the above (maybe changing big tables is not possible) is that you would be able to create a ‘Master’ App and that copies from that Master App would always follow changes you make to the Master App. This way you could create SAAS like apps with Glide very easily. **
This would be an enormous increase in value proposition of Glide (more people would be able to onboard Glide apps → Agencies would earn more money → Glide would earn way more money). I will add this as a new feature request!

Yes, that’s what I understood.

That wont work - as I guess you’ve discovered - because you can’t take a joined list of a computed column from a Big Table.

However, there is a workaround - and this is something that I have used, so I know it will work.

  • Start by creating a Query, matching the SupplierID of the one you want to update.
  • Take a Joined List of RowID’s through the Query (this will work, because it’s a non-computed column)
  • Feed the Joined List into a JavaScript column that processes the list of RowIDs, and outputs a JSON collection of API mutations, each of which updates your Text column with the new name
  • Use the JavaScript column in a Call API action

As I said, this works perfectly well. I’ve actually been using the technique to good effect just in the past few days. The only thing you need to watch out for is the upper limit (500) on mutations in a single API call. If you need to update more than 500 rows in one go, then you’ll need to batch them up.

oh, I should add - even using this technique, you’ll still be using an update for every mutation - so that part of it won’t change.

1 Like

yes, you can - see my previous reply :point_up: :wink:

1 Like

What an awesome Idea! I was tinkering with the Row ID’s too but as my knowledge of Javascript is nearly non-existing, I didn’t think about this.

Note to self: learn javascript!

However, I found a workaround with Glide AI which is totally No Code:

And the result!

Gotta love the power of Glide <3

1 Like

hahaha, 10/10 for thinking outside the box :rofl:

It took me at least 20 minutes or more to write and test my JavaScipt, and you got the same thing in 5 :facepunch:

1 Like

Allright @david. Now that we know that you can actually achieve updating simple text fields of associated rows in bulk (up till 500 row edits at a time which will cost $5) and that this solution puts Big Tables more on par with normal tables, isn’t the current pricing model for row edits through API-calls a bit too limiting? Allowing a friendlier pricing model for API Calls would make really big applications (lots of users/data) more doable in Glide vs going to another No Code tool (which would be my standard thinking now).

Of course, implementing this change (which is probably huge in development work for the Glide Team but also fundamentally changes the amount of value Glide can deliver to the world) would also be a solution as it allows using Normal Glide Tables in SAAS-like solutions: For Agencies: "Slave Apps" that follow changes in a "Master Apps" (Semi-SAAS/Template Alternative)

Beware with the output though, make sure it always only return the JSON and not anything else. If it’s too nice and say something like: “Here’s your JSON” then you’re screwed.

1 Like