Forum Documentation Showcase Pricing Learn more

Caching API calls in Bubble possible?

#1

Can Bubble cache API calls so I can avoid having to execute the same API call?

Thanks!
-Cody

#2

From what I know, Bubble automatically caches API Calls if you use them as Data source.

Can’t speak a lot from experience, as I mostly use them as workflow actions.

#3

My answer is relevant both for API calls but also for regular data queries from bubbles own DB. If using API calls you can set the API response as the data model for your state (see screenshot), For most implementations I prefer using a Data API instead of Action API since I only need to rely on 1 step in my workflow.



Caching results to states in your application can be very useful when you dont worry about content being updated automatically or frequently and the results list is not too long.

Set up the new State, for example on your page root if the state will be used multiple places on the page and not just inside a specific area/group. Then ensure the state has a type using the same data model for what data you are querying (API/Internal Thing), thereafter save the result to your state using “Set state” in element actions of a workflow and query your .
You could define your own logic for when to re-fetch your data, for example by using a workflow to set the cache state again. To ensure you only update if X time has gone you would have to create an additional state to store the datetime of your API call, and put a conditional on your workflow to ensure it only runs IF x time has passed by (for example time-state + 10 minutes).

Another way of caching is by fetching data in an invisible repeating group using a search for query or data api call. Thereafter, multiple other places in your application you can filter*(client side filter)* on this repeating group’s results. To update the results for data api calls you would have to make a change to the datasource by workflow (sometimes requiring a change in API call parameters - resolved by adding a non-existent parameter in your api call that you change the value of.) It could be a random number calculated and set as another state, then being referenced in your api call. To fetch again, just set another random number to the random state using a workflow.

Keep in mind that states ONLY persist during the page lifecycle until page is changed or refreshed. To go even further down the rabbit hole and persist API results across page change or refresh, you could store the received API call on the user by creating a new field with the API call datamodel
(see screenshot):


OR (advanced) in localstorage OR other places, depending on if API result is user specific or have security considerations, BEWARE if API responses contain sensitive data, think about where you store them and what privacy rules affect who may consume that data.

To be honest, in most implementations you do NOT need to worry about the complexity and potential headaches of going through the above as I think Bubble is pretty excellent at handling these things, but there are edge cases where complexities as these comes in handy.
In my experience, if you are not using the above approaches, Bubble do has some batteries included magic optimizations in regards to caching that makes your life easier.
Would be amazing to have @josh or @neerja chime in on their caching practices for external API calls as this may be useful for people searching the Forum going forward…

When only relying on Bubble’s own caching I have experienced solvable inadvertent caching issues if using data references through “current user’s datatypex reference’s dataref”
whereas a “Do a search for” resolved the issue for me.
most probably due to a websocket listener not being attached on the former. I may be wrong but just my impression.

ALSO - A notice for people having issues with unsolvable real time data synchronization - is that, somehow (not sure if this is still valid) - you may face issues with certain privacy rules AND/OR not receiving websocket* notifications for Data Things that has been created by ANOTHER user. If anyone ever faced these issues and still are I would love to shed more light on the issue itself.

*A websocket connection is a real time connection between your browser and Bubble. Your application subscribes to updates for whatever serverside Bubble Data your element(s) are referencing or displaying. Bubble then notifies your browser in real time that changes or new data is available for what you are subscribed to, and your client side app then requests an update of this data.

7 Likes
#4

Thank you @gurun for your helpful response and mentioned caching practices.

For confirmation, @emmanuel and other Bubble moderators - If possible, please let us know any details Bubble has already integrated and has to offer in terms of caching API calls. Also, if there are any additional caching methodologies to add to @gurun 's response, that would be awesome!

Caching API calls would potentially reduce the capacity usage of everyone’s applications tremendously.

#5

They do cache the calls - I had the same question months back. To make it not cache, simply add a Date to your API call of “Current date/time”.

2 Likes
#6

Adding a date field to force a refresh is very bad idea. You’re forcing bubble to evaluate and make api call every second (or whatever min unit you specify)
Don’t do it.
See Copilot’s detailed explanation on the implications of doing this in that thread.

2 Likes
#7

Very true - Definitely have to be careful on adding that! Has to be done right to prevent that.

2 Likes
#8

EDIT: @seanhoots I re-read your reply and see you might have replied to w.fly and not me :smile: - in that case disregard the below. –

You are right @seanhoots , when using evaluations that run continuously thats not efficient, and prone to issues - Thanks for highlighting that!

To be clear, so there is no misunderstanding, the approach I suggested was not to run continuous evaluations - it would only be running the workflow when he would want to fetch data from his API (on button click or when a view is shown). And it would only compare the timestamp of last time API was queried and see if X minutes has passed, it would only run the external API call if that time has passed. Thus giving the developer his own “rules” of caching/fetching on an API he does not have control over - for example. This is indeed for special use cases.

In any case, as I mentioned originally . and as @w.fly confirms. Bubble does cache calls by default using some internal magic that works for most situations.

Hope that clears up things :slight_smile: Have a good weekend everyone!

1 Like