If I “Do A Search For…”, it pulls every single column of data for that one ticket (Approval-ID, Archive, description, etc. etc.).
By using the “Inspect” button in Preview mode, I find that even if I am simply looking to display a Ticket description, all columns of data are pulled… In this example, you can see Scope Association is also being pulled.
When we do a “Do a Search For…” , allow us to select only the columns we wish to pull data from. In my example above, if I just wanted to pull Ticket Description, it wouldn’t pull the Scope Association and all of that baggage! (Another forum post talked about adding a Privacy rule, however I feel this would be straightforward).
For the programmers out there, this would be similar to how SQL allows a SELECT statement to choose columns versus a “*” to gather all columns (I know Bubble’s database is not SQL). A major performant gain for larger applications.
Giving us the power to reduce the amount of data we are bringing to our pages should bring an overall benefit to performance as a whole.
(Is it possible that this is already implemented and the “Inspect” button that I’m getting this information for is showing me all the data just to help with debugging?)
Note that the Inspector HAS to pull that data. It’s not necessarily true that all of that data was downloaded to the page were you not in test mode and inspecting the element.
Your parenthetical question at end is correct. While it’s hard to tell (because it’s hard to test without LOOKING at the objects and hence pulling them from the database), we are told that – and there seem to be – optimizations in terms of what Bubble actually downloads to the browser.
One thing, BTW, that at first seems a little strange when you start getting into Bubble internals (via building plugins) is that Things (custom datatypes in the database) are represented by their unique IDs. If you want the value of a field on one of those Things, you have to explicitly go and fetch it.
So, you do things like map the array of Things (which are just represented by an array of objects which have some functions on them and so are quite small) to an array of actual data values (which may be quite large, e.g., imagine an Airbnb type app where you have a Listing and the Listing has a list of Pictures on it and there is a field in Picture that holds the image data itself).
But we don’t – without explicitly asking – get the image data from a Listing’s Picture’s List’s:Item x’s: Image_Field without executing a get for that data. I can only imagine that the Bubble runtime works in exactly the same way. It needs to make certain assumptions about what to grab, based on the dynamic nature of Bubble, but it most definitely does not grab every field value from every thing all the time.
That being said, you can watch memory settings in the browser console and see that it sometimes seems that Bubble is getting an awful lot of data to the browser, even when one is explicitly referencing (in one’s Bubble editor programming) only a few fields of a certain Thing.
Where is the overhead coming from? Hard to say sometimes. But one thing I’ve learned is that some Bubble elements (not data items, but page elements) are quite heavyweight and I think that sometimes the apparent overhead is coming from element structures (RGs and the like) and not from “too much downloaded data”. I could be wrong, of course.
Not exactly - Constraints limit how many rows of data come back (how many tickets are status Completed)… What I’m talking about is for each row of data coming back, limit the amount of columns that are being pulled as well for that row (how many tickets are status Completed but only give me the name of the ticket, not the 20 other columns I have for the ticket).
P.S. The only reason I thought this may have been an issue is I store a lot of data for 1 ticket. What meeting it is part of, what scope of work it is for, which client it is there for, etc. etc. Figured I could squeeze out some performance by only grabbing particular columns.
For now, I think Keith’s answer is solid - There is behind the scenes action that is only pulling the columns I need. I’m sure that has to be the case.
My understanding is the bubble grabs the full thing anytime it’s referenced. This is, indeed, one of the sources of slow performance. It’s particularly noticeable when 1) your database tables get longer, 2) you add lists of things to a table (the list of things gets loaded to the client too), and 3) you load repeating groups to the page.
I suspect this is a very large opportunity for performance improvement with Bubble, but it also seems to be a bit complicated to address. For example, I suspect Bubble is caching lots of data rather than grabbing it directly from the DB each time. As such, if you only grab a part of a thing one time but then a different part the next, it may go around the cache each time which is a bit costly in terms of DB performance (and, essentially, trades one performance problem for another).
Without knowing the internal of Bubble, it’s hard to figure out what solutions may make sense but it’s certainly a huge performance opportunity for Bubble. And, it’s particularly important for the more robust applications that use Bubble because they’re the ones who have accumulated extra fields on their tables, which are often required for more complex apps. These are the same apps that really care about performance and also cover a large portion of Bubble’s revenue.
In the mean time, I do suggest Bubblers use privacy rules to narrow the list of information that’s available to each user as that’ll limit the amount of data sent to the client (thereby increasing performance).
I have a very similar situation where apparently I can’t apply privacy rules, as I need the data to be available to all users.
When we reference a type by its ID to get the data on a page, it gets all the columns even though the UI might only need a few to render. Being able to define at individual page level, what particular columns should be fetched, could definitely help in performance. Of-course, I don’t know any other impact it might have especially in regard to caching, etc; but definitely should have some performance improvements.
Hopefully, the bubble team improves something along these lines in the future.
In REST, the shape and size of the resource is determined by the server. In GraphQL, the server declares what resources are available, and the client asks for what it needs at the time.Source
