Just wanted to share a fix or a workaround for complex data structures when using @ZeroqodeSupport Fuzzy Search plugin. Thank you Zeroqode for your help.
If your Fuzzy is consuming a lot of workload units, or it is not working with complex searches, try this. I’ll share my example.
Summary: instead of “Do a Search for… Things”, create a custom state “Pre-Loaded… Things” and use it as data source.
Step by step:
Create a custom state “Pre-Loaded Golf Drills”, in my case this was for data type “Golf Drills”
In workflows, on page load, set state to “Do a search for Golf Drills”
Then in your repeating group data source, don’t use “Do a search for Golf Drills”, instead, use custom state “Pre-Loaded Golf Drills”
Then, in Fuzzy’s data source, also don’t use “Do a search for Golf Drills”, instead, use the same custom state “Pre-Loaded Golf Drills”
This saves a whole lot of workload units because “Golf Drills” are loaded only once on page load, and each time the Fuzzy search is triggered it is searching for the pre-loaded custom state and not the data in the servers. In other words, by doing so, Fuzzy’s consumption technically consumes 0 (zero) workload units.
First screenshot - set custom state to search for all drills
Not sure this is accurate - its my understanding that Fuzzy Search will load all the data on initialization, and then essentially store that in memory, so that any search utilizing Fuzzy Search will filter based on that data.
In both cases, if you reload the page, it will perform the search again to populate either the fuzzy search temporary memory, or your custom state.
So I don’t think this will save WU’s (unless you can show me otherwise via network tab in terms of whats been fetched).
Since it’s now referencing a state instead of a Search, the plugin won’t make any calls. It will work with what is in the state.
This is just the nature of how data sources work in Bubble. Any and all Search set as element data sources will run their queries when either the element is visible or the element’s data source is referenced. Hence why privacy rules are important as they prevent unnecessary values from being returned client side. Breaking datatypes into parts also help tone down the WU costs.
Use Search in data sources when you explicitly need realtime updates to a Search result. Using WFs to store Search results in states is actually the recommended practice. For some reason a lot of new users don’t know this…so they end up complaining about WU costs.
Note that while Search can be controlled, realtime updates to individual records (A Thing) are not.
But won’t storing full results in a custom state be really expensive and may even break the browser if the number of elements is high? Or is it like Bubble will apply some intelligence and get only some elements?
I don’t know about the inner workings of the mentioned plugin, but one thing is for sure: if you store an unconstrained search in a custom state and the plugin works with that in the client-side you will be sure about the total WU spent, and it will be the one of search itself.
There are drawbacks in using this strategy of course. You are indeed downloading ALL records, which can consume a lot of WU, potentially even more than those spent by the plugin working without this strategy, bloating the browser in the process.
@karaulal maybe you can share your experience on what happens if large set of data is used as the source. Maybe you can benchmark on 1K, 10K, 100K, 1M, 10M items?
Large data sizes will kill performance in any browser-based app. It is even more problematic with Bubble since we cannot save data into local storage directly, it still gets loaded into browser memory first, even when using local storage Bubble plugins. Unfortunately there is no “Bubble Intelligence™️” to stream large chunks of incoming data.
This is why the Fuzzy Search plugin is never a good match with large datasets. It’s better to run a search WF then to deal with WU costs and performance degradation trying to integrate fuzzy search with any Bubble plugin in this scenario.
