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.