More than 5 seconds making a filter

Hi everyone,

I hope you’re all doing well. I’m currently facing an issue with the performance of my Bubble app. I have a database with two related data types: newsletters and ads. Each newsletter can have multiple ads, and each ad has a price associated with it.

I’ve set up a repeating group that filters newsletters based on certain conditions, as shown in the image attached. The database currently contains only 30 results, but it takes about 5 seconds to display them when the page loads. I’m concerned that if it takes this long with 30 results, it might become significantly slower with 1000.

I’m not sure if the filter is inefficient, causing the delay. Do you have any suggestions on how to improve this? I would greatly appreciate any advice or guidance.

Thank you in advance!


Hi @hola14 :wave:

The Advanced filters are really necessary?!

Can’t you “Do a search for newsletter” and use this conditions to constraint the search!?

Inefficient might not be a strong enough word :sweat_smile:

4 Advanced filters with intersects and list operators? That will absolutely run your app to the ground.
As @rpetribu said, you need to move the filtering onto search constraints.

Advanced filters needs to be avoided on your main filtering operations. They are not run on the Servers, they are run on the client’s computer. Adv filters can be useful, but only on small numbers of things, typically on list fields of Things which you know have very few things, AND they should be filtering operations which are going to be hard to replicate by using search constraints or would require a big database design change.

Move all the search constraints onto the search. Is your search even constrained at all right now?
You might think this is not possible, but it always is.

The first one:
Change it to ** Newsletter Name contains Listado_minuscolas’s value capitalised.**
Make sure your Newsletter name is always capitalised when you save it to the database, Run :lowercase:Capitalised when you save it. If you really want to let users save Newsletter Names with weird capitalisations like BeSt NeWsLetTER in the WORLD, I would add a redundant field that saves the wonky text, but filter using the formatted text.

The Third & Fourth One:
Add a redundant field on the Newsletter which contains the Max Price and Min Price of its newsletter, and constrain on that. 100% justified redundant field and database change.
Make sure to keep that field maintained when the underlying Prices of ads change.

The Second One:
This is the trickiest because of many-to-many relationship. It’s also the one slowing down the search the most. Search the forums, this has been discussed before.
You might not like this answer.
Filtering based on list fields containing an element from a list is not good practice. Best approach is to create a junction dataType for newletters and categories. This means creating a new dataType which has a field for Newletter and a field for Category. If a newsletter has 5 categories, it would have 5 rows on this table, all sharing the same newsletter. This would allow you to run a search where the constraint reads: ‘Category is in List of Categories’, instead of having to run an advanced filter.
I would actually put all the fields on which you are filtering here, and use this dataType for the search, and then using Newsletter:unique elements to populate the Newsletters.

The above is industry good practice, but another way is to use a custom state to store the list of Newsletters and using the ‘:merged with’ / ‘remove list’ operators as user select/unselect categories.

Hope this helps.
I know its a lot to digest. But you probably need to find a way to reduce the long load. (Which will get much much worse with 1000s of things)

You were right, at least some constraints were necessary. We applied this solution to launch it in our MVP, and then discovered it was a mess :melting_face:.

Thanks for the quick advice!

Hello, hello @rpetribu. Wow, we are so grateful for your response :smiley:, as you mentioned, it took a while to digest, but we went point by point applying all your pieces of advice.

With the first one, the problem we encountered was that Bubble is case sensitive so, as suggested, we applied :lowercase:Capitalised (With a truncated) to the constrain comparison.

We solved the third and fourth as you were saying, saving the data in the newsletter instead of having to search for it in the ad table

For the second one, you were correct (again) the tricky thing is the many, to many relationships so what we did was save in the database the categories formatted as text and in lowercase.

Again, thank you very much for taking the time to go point by point checking all those filters :blush:

Now it is charging way faster :zap:

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.