I’m trying to get a better sense for how much we should lock-down excess database fields using the database privacy options.
Today, what set of database values are loaded to a thing’s page? Is it:
The data that’s displayed on that page and/or used as conditions in workflows or actions
All fields for that thing + ID’s for lists of things on that row (excluding, of course, the ones where privacy rules prohibit it)
All fields for that thing + all fields for things that are included as a list of things on that same row? (so, if a user has 5 friends …are his friends’ rows also loaded)
Yeah, I had tried that but have trouble believing the results. When I do that it loads the thing and all fields for each thing that is included as a list of things on that parent record and all of the things that are included on the child thing as well. So, in my case, to load the original thing we’re sometimes loading 1,000 other things and all of the data for each of those things – that’s a ton of unnecessary data to load.
Here’s an example: when I have an “Event” table and each row has a list of registered users and on my “User” table each user has a list of interests. Then, when I load 1 event, it loads the following:
Data for the 1 event
Data from each registered user for the event (e.g., events often have 100 registered users)
Data for each user’s interest and all associated fields (e.g., users often have 10 interests)
So, we’re loading 1,001 things in order to load 1 event - that’s 1k more than is needed. No wonder some Bubble apps are so slow!
Hey just wanted to touch base and see if your above post is true…
I’m optimizing at the moment and am thinking if what you say above holds then I would be better just having a list of the CHILDS uuid’s and then accessing them like that rather than have bubble automatically load all the children. Would get super taxing if there are many fields and images.
Do you what do you think?
I guess the pros would be loading less so hopefully faster speed however to access the thing you would now need to do a search,
“coding” so to speak would be slower as you cant just click your way through the Parent->children->thing
I believe it’s how Bubble works, but not 100% sure at the moment. These are definitely the results I saw through the debugger though - so only way I can imagine it’s not true is if Bubble does something different when the debugger is on, and that defeats the purpose of the debugger. So, highly likely true.
I should mention - I don’t think the images are loaded unless they’re displayed on the page, just the URL is loaded to client so they could be retrieved. If it worked differently, this would adversely impact performance much more.
While loading a lot of unnecessary data makes it slower, so does doing an extra search. So, going the route you’re talking about won’t necessarily be faster. For context, in 2018, webpages average ~3MB so 1,000 extra things impacts that, but is only a small portion of a typical page.
Additionally, depending on your project, it may be wise to assume that Bubble improves and gets smarter every year, so just because something is seemingly poorly implemented in Bubble today doesn’t necessarily mean you should work around it.
I guess the question is whether it loads it all synchronously or not.
Don’t think so, as if you look at Chrome Dev Console, and check out the resource calls, you can see mgets towards the end after the page is loaded. (not sure if this is Reddis ?).
How Bubble decides what it needs to load up front, and what to loads after …
Is there any way to prevent this “loading everything” behaviour? In our app we need to filter the children item by the current page’s thing (for example, Current Users' Pages:filtered(page = Current Folder's page):first-item - that’s not my use case, but that’s the idea)… but the children items are large and there are potentially a lot of them if the user uses the app a reasonable amount.
In my testing I noticed that I end up with some HUGE requests as the user has more children items (even though I only ever need 1 of them to be loaded). An average user ends up having to load several megabytes to show a simple page - and that is way too much on mobile, and sometimes causes Bubble to timeout and throw errors.
Is there a way to optimize this without completely re-writing the structure to be non-normalized?
When you use “:filtered” it’ll load the query before that to the page and then filter it client site. So, if there’s a way to add the filter logic to the Search for (which is done in the database) then that’d be much quicker.
Personally, we’re also looking at using Algolia to create and store search indexes that we can use to flatten tables and pull the data back quickly. You could also do something similar without using Algolia where, essentially, you create a new table that you use for this particular search. Then, anytime a new record is added to your database that’s relevant for this table then you add or edit this extra table as well. I believe this is what custom-code apps do all of the time - and these are often called search indexes and/or denormalized views. It’s a bit more complicated to maintain, for sure, but it also gets you better performance since you’d be able to search a single table and not bring all of the data back.
Thanks for that! I’ll certainly be trying it out. It’s annoying that we’ve run into it now, because we’ve been playing pretty fast-and-loose with :filtered - it’s used for showing/hiding things in the design view and for many parts in the workflow. But now that I understand it makes sense!
(Also, perhaps evaluate GraphQL if you haven’t already… I think it would be a perfect fit for Bubble!)
