Hi everyone, I need a little help to figure out how to reduce workload consumption. I make a call from the API connector and have “Attempt to make call from browser” checked. I have verified that the call is indeed made from the browser so it should be bypassing bubble completely.
However, when checking my App metrics > Workload by Activity that API call shows up as the action that consumes the most workload under Fetching Data > Search. In the screenshot below, it is the teal section in the pie chart.
Why is this costing me WUs, especially under the activity Fetching Data > Search, considering this is an API call made from the browser and is done all client side?
Search is not API call. What do you get if you continue to click on the search?
Even fetching data itself is not API. Fetching data are related to Bubble DB. If you go to overall, you should see External API request for all the API request
The image I posted was after I clicked on Search, and the teal section of the pie chart represents the API call. Yes, I didn’t think API call should be listed there. The only thing I can think of is that I have that one API call set as the data source for the element on the page.
When I check External API request I don’t see the one in question listed in there, and overall, External API request is using a tiny fraction of my WU compared to all the others.
What I do is whenever I “Do a Search for” something, I attach it to a reusable component that is on all my pages. Inside this element I can set states, and the data consistantly throughout my app.
This is easily accomplished by sending your state (your API data you fetched prior) to your other reusable elements throughout your application, therefor the data only needs to be fetched once on page load (or setup a flag to update the data on an interval).
This will prevent you from searching for a data-type more than once, and can scope easily from your source from anywhere.
Page
[Reusable] HEADER (A state inside here is where your data lies)
Content
– [Reusable] Page (takes a prop for any data type) - Set it to the headers state.
Hope this gives you more insight on WU optimization.
Are you sure? Pretty sure it’s a fetch still (technically).
If you click on Fetching DATA, you will find a second layer of data that will show Bubble DB fetching data like Search, Aggregate, Groupby, Individual data request, realtime search and autobinding. Clicking one more time on them will bring you to the expression itself. Clicking on the expression will open the editor where you find this expression.
If you click on API you will find mostly two types: Workflow or Data. Clicking WF will open a new level wher you will see each item actions and clicking again will send you to the Backend WF. For data, it will just open the DB related to this Data.
Finally External API request will directly open the chart level where you can see all API Call. But seem to only display DATA type call. Not action. I guess that actions will be find in workflows or in Backend WF section.
@bensonlangley If you don’t find the API call performed in Browser, this si probably because it’s doesn’t consume WU.
About using elements as anchors for searches in order to not have multiple time the same search: I also do the same however according to Bubble’s documentation, they should already take care of this in their own app optimisation.
It can be. My app I’m currently working on is not really a SPA, it has other pages with the header attaches on it and I use the same data source from that element on all my pages.
I just don’t see this actually happening when I look at the logs. The data get called more than once.
Your parameters are retrieving data from DB objects and that’s most where the Search costs are coming from.
Those don’t cost much as they are referring to the current page object and User. If you believe that it’s costing too much WU, the frequency of the call is most likely why it is blowing up. As also hinted by @GH5T.
Things you can look out for:
Is the element in question in a repeating group?
Is there any WF that is causing it to make the call repeatedly?
Are you making any additional Search calls in your :formatted as text expressions?
Really surprised Bubble hasn’t introduced any Redis based functionality. It’s streamlined on all major applications. I use it on my own applications. KV storage is so powerful. But hey, guess they want to keep overcharging us for not caching data that should be cached. Tree has to get water somehow I guess.
A suggestion would be to cache the data yourself. I use my Toolkit plugin to use cookies and local storage. These help me add data into the user’s machine that isn’t secure nor intended to be. Things like blog posts, updates, notifications, etc., can all be cached on the user’s machine. You’d want to create some additional logic to update that cached data, and enforce it when necessary. This solution will prevent API calls being made, and it even renders/loads data much faster. Though, it’s somewhat tedious to set up, it’s very efficient.
So if I have a reusable header and I put onto it a custom state that is a list of things, and from Page A I set the custom state of that list of things on the reusable header, that when my user navigates to Page B or Page C, whereby the page is loaded, that the values in the custom state on the header set from Page A are still set on the header that is visible on Page B or Page C without needing to run a set state action and that there would be no need to refetch those values from the database again, implying the values carry over from the reusable on Page A to the reusable on Page B or Page C?
I was always under the impression that each iteration/use of a reusable is materially different from another, as we can use the same reusable element more than once on the same page and have the ability to set different values to the custom states for each of those. And I was also under the impression that when a page is loaded all custom states set are lost and would need to be set again.
I’m very intrigued by the concept you outlined, but feel as if I am lacking clarity on how it is implemented.
I’ve only recently began utilizing local storage in apps and really like what it can do, especially for remembering who a non-logged in user is.
When you use it for things like blog posts, are you saving to local storage the blog posts as JSON? I’m curious how to make use of this in an app.
Yes. As long ad the element is on the page, it should have a unanimous connection. As long as you’re not fully reloading the page, it should work and behave as expected. For my example I have 1 Merchant search being used throughout my entire application with one call, feeding to all my inner elements that require that information.
JSON object inside an array, pretty simple. With localstorage you’re able to modify any key/value. However, you are limited to the amount of data you can store (5mb per web app - which could be throttled by user not automatically, so not recommended for any big data).
