I understand the Call API function in both an Action and Computed Column context.
In our case, we are considering a customer portal which would allow customers to access (amongst other items) their appointment data. Across 15,000 customers (set user pricing to one side for a moment!) this would be a lot of standing data to keep up to date on any period that would be useful to people logging in.
An inspiration is Gladly, a customer care system that has something they term a ‘lookup API’ - this system automatically triggers an API call and loads the results when a customer file is accessed. As such, you can maintain one system of record rather than having to synchronise constantly, but you only access that system when it is relevant.
It would be awesome if Glide could implement something similar, i.e. an API call is fired and the response loaded in say to a computed column only when that row is accessed in a set way (e.g. a detail screen) - I imagine you’d have a toggle for a component or screen saying ‘update API calls for computed columns’ or similar.
Nope.
As I say in my message I understand the Call API function as it stands.
As far as I can tell, there’s no way to trigger the Call API when accessing a row in your app - you can either access on demand via actions (which is not very good for presenting dynamic data) or periodically for a computed column, which could potentially consume vast amounts of updates for data that isn’t accessed.
Maybe I don’t understand your question, but are you saying that you don’t want any caching at all? So 15,000 users would trigger 15,000 updates over and over and over again every time a user so much as looks at a row. You would blow through your update limit in a matter of minutes. What I shared is a way to set the cache time, so even if it’s only set for 1 minute, it should still refresh the cache if a user is accessing the data. Are you saying that even 1 minute isn’t sufficient?
In my example context, a user needs live appointment data when accessing their account. The data needs to be live to be useful.
If you have 15,000 users, and you accept say that appointment data should update every 1 minute (which itself is still a period that would cause a potentially poor experience) to be useful that is 15,000 API calls per minute. The volume of updates would be astronomical, ignoring the rate limit issues.
Of those 15,000 users, if 1,500 used the system once per month to review their appointments, that is only 1,500 updates. By using a cache, you are forced into assuming the whole population may require access at any time and exactly on the periods you set. By allowing access on demand, you actually vastly reduce the workload.
In short, if you need access to external data in a live context for large populations as far as I can see the current system has no ability to cater for this in a sensible way. This would be easily fixed by allowing a Call API Computed Column to trigger dynamically when accessed.
Glide doesn’t cache its own relations / lookups as far as I can see, it runs those queries on demand - my request is simply to have the option to repeat this behaviour in Call API columns.
Unless I’m misunderstanding, this is quite trivial.
Call API can also be used as an action, so all you need to do is build that into your navigation flow.
That is, any time a user navigates to a screen where they would expect to see this data, trigger a Call API action that fetches the latest data. If the user would do anything in that screen that would cause the data to change, then again you make a fresh API call a part of the associated action.
3 Likes
I appreciate Call API can be used in Actions. What I can’t see is how you trigger an Action based purely on navigation (i.e. arrive in app, action is triggered).
A workaround may be to build an action that includes the api call based on a button - e.g. in my example have an ‘Appointments’ navigation button that has an Action that (a) makes the API call and (b) opens a new screen, showing that data.
That is still a level of interaction (i.e. an extra step) that could be avoided if you could trigger an API call based on accessing a row, rather than a specific action or periodically.
Maybe that is trivial, but given its how Glide approaches relations / queries as far as I can see I don’t think (a) it would be difficult to implement and (b) would extend functionality considerably in certain use cases.
I would encourage you (if you haven’t already) to have a look at Gladly’s Lookup API. I think its a superb implementation and works really well for its users; it opens up a lot of use cases. It’s limited to Gladly’s purpose of course, but it isn’t a difficult concept to understand / extend. See also their App Platform.
See: Introduction - Gladly Connect
No, you can’t do that. At least not yet. I have seen some early concepts that suggest it might be possible in the future. But for now, yes you do need some sort of user interaction to trigger an action.
I’m not quite clear on what you mean by “accessing a row” - do you mind elaborating on that? Perhaps with a practical example?
1 Like
On your latter question, the trigger to call an API is currently:
- Periodically, if using a Computed Column
- On Demand, if using an Action
In my use case, you introduce a third option which is when you access the data. To elaborate, I mean that when the record is accessed via your app to present data to a user.
I imagine you would have a new option for a computed column, which is ‘on demand’ or similar. Then in layout editor you could specify which layouts / components would trigger that api call (i.e. you could create a list component that doesn’t, but a detail component that does). This would allow you to retrieve and present data on demand, without relying on a specific interaction from the user to retrieve it (a small compromise I guess, but a compromise nonetheless).
The concept is very similar to a Relation - there is no user interaction required to trigger Glide to retrieve data via a relation/lookup, as soon as you access the data in a layout component this happens.
The Gladly approach works on exactly this basis - when an agent accesses a customer record (i.e. a detail screen), all external data linked to that record is updated via API calls - it is simply the action of opening the profile that generates the API call.
Yes, that’s where I’m kind of confused. You can do exactly this with Glide. As long as you’re not opening the App directly to the details screen - which is possible, but not a typical use case.
A more typical use case is where you present a collection of records, and a user selects one to view the details of that record. In such cases, the default action is to “View Details” screen. But that’s just the default. It can be changed. So you could modify that action to first make the API call to fetch the data for the selected record, and then show the details screen.
Does that approach not work for your use case?
Not necessarily.
This said, I think understand the point you’re making. Maybe it is trivial. And relying on a navigation action would work probably work fine in an internal app where you have a number of records to choose from, i.e. you’re happy to look at parent records say in a list before looking at child records in detail.
But for a customer facing app, the app might be limited to one parent record (i.e. the customer) and therefore you create a level of navigation in getting to the child records (i.e. appointments).
This makes for a slightly clunky interface where a customer would need to login, then select a button (rather than navigate to a page, or even look at a home page / dashboard) before they could see the relevant data.
In this use case, you might want to show details (e.g. a summary of appointments) immediately after login. Relying on a navigation action would make for a less seamless navigation experience and a limited dashboard / welcome.
It would also mean your app fails / breaks if someone bookmarks or is directed to the child page directly. Users are prone to this. You’re forcing a journey that users (in this case, consumers) will almost definitely find a way to circumvent.
1 Like
Okay, now I see what you’re saying. You’re basically deep linking a user to a specific details screen and you don’t really want them to navigate away from that.
That’s fair enough, although I’d still maintain that you could still have a fairly decent user experience. Even if it was just presenting the last cached data with a timestamp, and a small action row button to trigger a refresh. Or perhaps it’s sitting in a container and hidden by default, and a click is required to expose it.
Anyway, that’s what we have for now - user initiated actions. But Glide are thinking about other ways to trigger actions. Scheduled actions is something we will definitely see soon-ish I’d say. But there are other trigger events being considered.
1 Like