In my attempt to avoid using “Do a Search,” I ended up increasing the workload consumption. Quick context: I run a novel publishing website with a database for novels and their chapters. Normally, you’d set up the Chapter database to have a novel-ID field, allowing you to “Do a search for” the chapters and display their information.
However, I created a “List of Chapters” field in the novel database, linking each chapter directly. The problem is, when an item is called from the novel database, such as the novel description, it also loads the information for every single chapter under that novel because of this “List of Chapters” relational database setup. Took me a while to figure this out because all i could see was the individual data request which doesn’t point to any element had sky rocketed over the last 3 days.
I’m about to revert to the previous solution, but I needed to type this out to vent my frustration. That said, I’m back to using “Do a Search.”
So I assume you access the chapter name from the list of chapters on the novel datatype instead of doing 1 search for a list of chapter from the chapter datatype.
Yes, that’s correct.
I tried to avoid using the “do a search” expression, which consumes 0.3 Workload Units, by using alternatives that I thought would be lower.
For example, I used:
Novel’s List-of-chapter’s first item’s chapter-name
The equivalent “do a search” expression is:
Search for Chapter’s first item’s chapter-name
This worked fine, but when I called something like Novel’s novel-name, it also returned all fields for that item (even though they weren’t displayed to user), including the creation date, description, and importantly, the “List of Chapters,” which points to over 100 different chapters’ worth of information.
I almost never use nested lists inside of data, it loads slower, it costs more, and it isn’t as scaleable.
My rule when I develop is ONLY use nested lists on things with limited numbers of things <10 and does not infinitely scale. Typically I only use them to store option set lists in data though.
I’ve done app audits where they are storing thousands of things in those lists and nested lists have things that have more nested lists and it deteriorates the entire performance of the app to the point it’s loading near unuseable and crashing. Stack that with filters, advanced filters, or that data being loaded inside of popups and you have an app that takes minutes to do the initial load.
I apply the same concept as @chris.williamson1996. I do make exceptions for when i know that I will always be loading the datatype together with the list. For example I will always load a “project” datatype with all it’s “milestones” so I just leave “milestones” as a list field in “project”.
The idea is to be very mindful of what data is loaded whenever it’s loaded on a page.
You might be able to reduce WU usage by further analyzing the Logs and the details in the network tab of your browsers Developer Tools ( press F12 - tab Network).
The information for the chapters should not be retrieved (unless you are immediately filtering / showing it), you can see that when analyzing the data your browser requests and retrieves, check the Developer Tools (press F12 and go to Network) and look for the msearch and mget entries.
The JSON for you novels data will contain entries with ‘LOOKUP’ in it (see the example image below) for those list fields.
Not sure if i’m checking the right spot but didn’t find the mget or msearch.
So what i used was bubble’s preview tool for the live version. Though I’ve removed the most problematic nested list, i still kept one of them that wasn’t resource intensive. So if you look below at the image attached, to display the Novel’s name, the expression is
Current Page’s Novel novel-name
Now, further looking at the data that’s also retrieved during that call and from what i understand, it also retrieves creation date, modified date, and novel-detail which is a thing, all of which aren’t displayed. If you expand novel-detail (see 2nd image below) you’ll then see that it further retrieves novel-description and a few more details all of which consume Wu even though the actual call was just Current Page’s Novel novel-name. This was what was happening but I had a field for Chapters (which i’ve now removed) that would also call and retrieve the data for 100+ chapters.
When you refresh the page it should show you something like this:
True, it retrieves the fields of the data type (the fields exposed by the privacy rules, so you can exclude fields visible to the user using privacy rules).
Like I showed you before, it only retrieves the chapter data when it is displayed/filtered/used somewhere.
So if you are immediately displaying the chapter data and you can prevent that it should reduce WU usage.
Ps. when you are using the debugger and you click to open the list of Chapters, the data is also retrieved. You will see that mget-item appearing again.
