The more familiar I get with Bubble, the more I think I should rely on “Do a search for” in repeating groups rather than putting a filter onto “Current User’s list of things”.
Sometimes the search is a little slower, but if I could do away with having to keep those “lists of things” on various data types, that would be nice.
It probably depends on the application, but has anyone else decided to go this route, too - using search instead of having all these extra list fields in the database?
(I’ve asked something similar to this before at Is "do a search" always better than "filter"? but I still find myself thinking about it often, so wanted to see if there are any new opinions out there.)
Previously, I also thought that Do a Search for was the way to go for as many things as possible, but this is not ideal for situations where they could be hundreds (or thousands) of things to search for, and storing a list of Things and querying that instead is possible.
For example, in a messaging application, it wouldn’t be ideal to display a list of Messages using “Do a Search for Messages (constraint = Parent Group’s Conversation”. This is because even with a few Users, you could begin to have hundreds of Messages within the database, and using Do a Search for to display a specific Conversation’s Messages would take some time each time the User wants to view a specific Conversation.
Instead, it would be faster to store a list of Messages within the Conversation data type, and display them in the repeating group using Parent Group Conversation’s Messages.
Even if you need to filter that list of Messages further, using “Parent Group Conversation’s Messages:filtered” – will most likely be faster than searching through all of the Messages in the database each time a list of Messages needs to be displayed (depending on the filter being used).
As you said, I think it really depends on the application and how you many ‘Things’ you anticipate will be searched through, but I’m using lists much more than searches where it’s possible
Another consideration is how you look to build out your privacy roles. Generally speaking, the higher the degree of privacy for the thing(s) and defined relationship to a specific user, the less likely I am to rely on a search and the more likely I am to use a defined list.
Within those defined lists, the actual amount of filtering is fairly limited. (Ie. they would normally have access to the entirely of the list and can filter based on on-page constraints).
For example, if I’m building a messaging system, I typically build a “Conversation,” which stores a list of “Messages”. For each user, they have a field called Conversations_Associated, which is a list of Conversations they are involved in.
I find that using :filtered leaves me with errors a lot of the time during workflows. However, they usually work fine on the client-side page level. So these days, I use “do a search” during (api)workflows and “:filtered” on the front end.
@fayewatson, thanks, that’s a great example. What I don’t like about this approach is that it means every time I create a message (or a notification, etc. etc.), I have to add an extra workflow action to add the message to the conversation, which slows down so many of my workflows, but if it speeds up the repeating groups, perhaps it’s worth it.
I had actually done a test last week where I:
-Created 2000 users and 500 items and made some of those items “available”.
-Added 3 items to each user (“User’s List of Items”) and also added those users to each item (“Item’s List of Users”).
…which loads only a fraction of a second slower than this repeating group:
…which is why I thought the search was almost as good, but I could see how it could get worse with more data. It was just such an effort to create all that interdependent data that I didn’t go any further than this test. If anyone wants to see it, you can go to the editor below, “run as” any of the users, then go to the preview below.
Thanks @dan1, that’s also great advise, thinking about it from a privacy perspective. I’d started to make better privacy rules for viewing, but I had always just included the search privilege along with the viewing without really considering the impact. I’ll go back to look at that.
And thanks @gevestobs for that tip - I’ll watch out for it.
@philnauta Right! I see what you mean; it’s hard to tell in the beginning. It also depends on everything else that will be happening on that page, such as the number of elements and if there will be other queries/searches that need to happen at the same time. Also, doing a search for uses more capacity since it’s server-side and filtering a list uses less since the filtering is client-side.
Just as an example, in one of my apps, I had a tiny text element in a repeating group of 8 items, and that text element displayed the search result in each cell, after doing a search of around 30 records. This single search (which occurred for all 8 items in repeating group), added a 15 second delay to the page load speed time. I re-structured the data so I didn’t need to use a search at all, but it was just an example that even the ‘little’ things can make a difference.
I have this setup in my app as well. When I first set it up, the loading/progress bar at the top would show almost every time a new Message was sent (which made things feel very slow). I then moved the workflow into a custom event, and tried to eliminate any searches in the workflow section, which seems to eliminate the progress bar from showing each time. Is this what you’re experiencing?
