Hi community,
Here is a way to save massive amounts of workload units using custom states. (edit: goes from 700 to 26 WU per page load)
Use case (wrong): I had a repeating group and another nested RG inside of it. Parent RG holds dates, and child RG holdes social media posts corresponding to a date of parent RG. Quick way is to set the data source of the child group to “Do a search for social posts: (constraint: date of social media post = parent groups date)”. Why this is awful? Because a single page load uses 700 WU, for every given date of the parent group, all of the social media posts are fetched and only a few are returned - the ones that match the parent groups date. So with this approach you are loading entire Do a Search over and over again.
Use case (correct): this drops consumption from 700 WU per 1 page load to 26 WU per 1 page load. Solution: create a custom state “Social media posts”, then on page load, set its value to “Do a search of social media posts”. Then in the nested (child) repeating group, set the data source to the custom state.
Why is this so? Say that parent group has 30 dates, the first approach will load the Social Media Posts 30 times, once per date, while the second approach will load it only once. Once you have the data in a custom state, it is stored in memory and does not use additional workload units.
The arrow points to the custom state (approach 2) vs all other spikes are without custom state (approach 1).
This is helpful if you’re using Fuzzy search too. Fuzzy Search workaround that saves WU consumption
Keep in mind this is completely app dependent and no way a bench mark for other apps…the cost of fetching data in bubble in terms of WUs is heavily weighted on how many data items you return, which is 0.015 WU per item…so in your findings, you are right, you got nested data searches (long established best practice is to avoid; dating back to pre-WU pricing as it is a data performance drag) for each and every cell in the repeating group.
Only true way to reduce the WU consumption of searches in Bubble is to reduce the number of items returned.
1 Like
This is a long-winded way of saying that storing data in states do not cost “Real-time Search” WU costs.
Here is a WU activity chart from one of my apps. As you can see I have very little “Real-time Search” activity. That’s because I tend to avoid Searches as Data Sources when I don’t need real-time updates to a search that returns a list.
What’s important is knowing what is costing you WU in your apps.
Search
Any “Do a Search for” will count as a Search activity
Aggregate Search
Any “Do a Search for” with a operator that returns a count (:count)
Individual Data Request
Applies to any singular record of data that has been loaded into the client (visible or not). This pays for all real-time updates to a record. Even if the record is stored in a state.
Real-time Search
Similar to “Individual Data Request” but applies to “Do a Search for” set as Data Sources. It pays for keeping these Searches updated in real-time. Applies even if the Search returns a Single record.
Autobinding
Pretty straightforward.
If you understand what costs you WU, you’ll realize that WU is extremely manageable. It requires good planning and understanding. Which means reading the Bubble Manual, or as @keith always said RTFM.
Thanks for the guide through the multiverse. I think my post was clear enough
