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!