states = temporary data stores
repeating groups = real time database data
use states to temporarily store data for instance - user opens a pop up and drag and drops the order of a list of things - store that as states and when the popup closes or user clicks button then send the data to the database.
it is usually most performant to do the search in all 3 places you use the data - it’s not ideal from a dev perspective because it creates excess work (much easier to add 1 source and then just apply filters for the different areas) but it’s the most efficient in terms of bubble server usage.
ie if you have 1 repeating group that shows a list of the data paged to 10 entries
then you have counts or sums of all that data in cards on the page…
it’s most performant to search and aggregate on the bubble server and then send just the number to those summary cards
vs
reference the repeating group with 1000 records and then aggregate the data on the page - this forces bubble to send all the data for all the records to the page to then aggregate it (instead of just sending the 10 records in the first page of the repeating group and then lazy loading the other pages).
I’ve tested this a lot and there’s a big difference in WU costs. server side aggregations are very cheap vs client side aggregations that force the whole list of data to be sent.
1 Like