This condition:
…takes about 3 seconds to complete, which delays loading other elements on the page. What would you do to fix this?
(By the way, there are only 5 “Current User’s Notifications” so it’s not a big list to filter.)
Thanks!
Hey @philnauta
Possibly try:
Though not sure if this will work with you data types - lemme know result?
1 Like
We are aware that filters are one of the heaviest process. if you’re able to avoid it… would be awesome for you. Especially on page load, because the “page load” is the heaviest moment for a Bubble app and usually any website or app around.
1 Like
Maybe create a yes/no state “has_notifications?”
Execute workflow “when page is fully loaded” and perform that condition check and change the state to yes if condition is true.
3 Likes
If you remove the count (time consuming), for first_item found not empty ?
1 Like
Thanks everyone for the tips.
@luke2 I don’t think yours will work for me (or at least I didn’t see how) because the notifications aren’t tied to the page in any way, but thank you.
@vini_brito Yes, I had started moving to searches instead of filters but then some folks convinced me that filters would probably be better, especially when there’s more data to search through ( "Do a search for" vs. "Current User's list of things:filtered" (Again) ). Yes, more data means there’s more to filter through too, but not compared to searches (e.g. there will eventually be hundreds of thousands of notifications to search through, but each user will only have hundreds of notifications tied to them). I still don’t know which is right, but I’m sticking with filters for now, when appropriate.
@JonL Thank you, this sped things up considerably.
@JohnMark Thanks, this didn’t make a difference, but I could see it making a difference when the count gets huge.
1 Like
Yes I know! 
I don’t know if at this moment it’s still true. But having testing 1000 records, the decision was easy to removed all ‘count’ I can found and replaced them with +1 in database when possible.
Glad it helped a bit. In the end it’s just a workaround to defer the check so that the page can continue loading.
If you find a better way to optimize the query let us know
Oh, here it is!
there will eventually be hundreds of thousands of notifications to search through, but each user will only have hundreds of notifications tied to them
I’m pasting an answer from How can I optimize a search capacity-wise? - #2 by NigelG, hope it clarifies a bit more:
"Think of it as a sieve…
Try to get rid of the big lumps first. So in this case you want to filter out the 9,900 orders that are not for this customer as early and quickly as possible.
You can do that by having a list of orders on the customer. Then the database knows exactly what 100 things to go and look at first to see if it was in January.
What you don’t want to do, is search each and every one of the 10,000 orders looking for January, and then take that and search through all the customers to see if this is for the customer you want.
List > Search Constraint > Filter > Advanced Filter
Try to get as much done towards the left of that as possible."
Also, I took a look at the thread you mentioned, but I’ve seen the devs mention that searches are more efficient than filters in general, and I’m not sure that server-side is slower than client-side, but I’m not a dev. Usually it depends a lot on the page context, but I’d like to focus on what I pasted above instead of “filter VS search” discussion as the above (the data structure) seems to be the main issue for now.
1 Like
That’s good info, thanks @vini_brito. I would definitely say a filter on a search is a last resort. The trickier one is a search without a filter vs. a list with a filter. In the end, it seems to depend on the context which is better, but I’m going with the list with a filter rather than the search without a filter most of the time.
Yeah, that’s a good way to do it. Personally, I tend to use search on a list and I try to segment my lists as much as possible.
A sure thing is if you segment your list into smaller lists, it will improve a lot. Whether that’s feasible or even a priority right now is up to you, but if you hit on another performance wall, I suggest you to try to further segment your lists.
Just to clarify, do you mean “I tend to use filter on a list”?
Can you give an example of segmenting a list? I’m not sure what this means. Would this be like, instead of having “User’s List of Recipes” having “User’s List of Dessert Recipes”?
Thanks for your time.
Not really, I use “Do a search for” and apply search constraints in the “search” menu or just use a direct reference to a list when possible. For example, I have a Store that has a field called “basic menu”, which is a list of things called “base products”. In a page, for me to show these products in a repeating group I just select on the data source “Current User’s Store’s Basic Menu” and that’s a direct reference which apparently is the best.
This is what I mean about direct reference. Just point to the right stuff without searching or filtering.
About search on a list:
In another page I need to bring up a customer, so I have a search box input that the user will type in and it will bring the customers based on their “name” field. The list it searches on is a List on the store called “Customers”, that holds the customers that the store had previously recorded. That list isn’t shown here, but I defined it into my privacy roles tabs.
This is a search.
The Privacy Rule:
The user will only see Customers (Clientes) he himself created. Enforced at server level, so safer and faster.
The Searchbox input element looks into the List of Customers (called Clientes) that belongs to my Store (called Horta), instead of searching every customer from the database. That’s why the list approach is better, because it only looks into a small subset. Through privacy roles I made it so that the current user will only see Customers (Clientes) that are in his Store (Horta) list, so I didn’t applied that constraint directly in that search. Privacy roles are better and safer because the data doesn’t even gets sent to the user’s browser.
About list segmentation:
My data structure for now.
This is a “Horta”, which is a Store. It has its own list of Customers (called Clientes). Now, whenever I’m going to search something, I don’t search every Customer in my database (suppose I have 5000 of them). I’ll just search the ones that belong to this Store.
Stronger example of list segmentation:
Every store will generate about 1200 orders every month. I need about 60 stores to achieve break even. So 60 * 1200 means 72000 orders every month. Bubble restricts us to have up to 10 000 things or items (text, number, whatever) on a list, so I can’t even start to store orders in a single list in the store. So I segmented it further. I split that so that each Customer thing holds its own orders list. A customer will generate about 340 orders itself every year, and its list will hold about 340 entries after an entire year. This is what this looks like in my data structure:
Cliente = Customer; Pedidos = Orders. I do this instead of simply filtering through the tens of thousands of orders looking for the order that has a “belongs to customer X” field. This way I just directly refer to this list. Use direct references as much as possible, they’re the best.
Back to your app now: If you simply create the notifications in your database, you will have all of them in the same basket, so it is hard for you to find one, because you will have to “search for” or “filter” through thousands of items every time a page loads. Feels heavy!
So, if you store in your user a List of Notifications, and every time you create a Notification you add it to that user’s list… then you’re good. You’ll have to filter through 10 000 notifications at max, on page load. Still heavy.
What can we do then? Segment it even further! You got the idea: in the User thing create a field describing what the notifications are about.
Like this: Thing User
Seen Notifications List of Notifications
Unseen Notifications List of Notifications
Or: Thing User
Interacted with Notifications List of Notifications
Seen Notifications List of Notifications
Unseen Notifications List of Notifications
So when your user opens his page, Bubble will only fetch “Unseen” notifications. Which will probably be just some small stuff generated recently for that user. Then when the user focuses the element that displays the notifications, you can send them to the “Seen” ones list, that won’t be loaded on Page load, or even at the initial page, depending on your design.
Since every user will have only his small subset of lists, things will get a lot lighter, because Bubble won’t have to fetch every other’s user’s notification, just this one user notifications and only the “Unseen” ones to show first. Then after clicking the element it expands into something that shows “Seen” ones, probably filtered by “this week” or something else.
As for recipes, yeah, pretty much it.
So, to close it all: Use direct references as much as possible, then segment lists as much as possible and leave these lists at the Thing that has the biggest number of occurrences (instances) in you database so they aren’t one big segmented list, instead they are spread over small lists in several things.
Hope this helps, you or someone else!
4 Likes
@vini_brito nice explanation of list segmenting
This topic was automatically closed after 70 days. New replies are no longer allowed.