it’s christmas time and that’s time to think about something about architecture in bubble. maybe it’s possible to reduce the workload of my application and also get a performance optimization?..
The “user” record in my database stores an image for each user.
I’m using the user’s image on mostly of my sites. (to display users current login status including the user’s picture.)
My thoughts:
If a user is using my app and navigates to all of the pages (let’s say the user’s navigates through 10 pages). On every page the user’s profile image / picture will served to the users display… → does bubble.io’s engine always send a request to the database and run a query against it? If so (well, I really don’t know so far if bubble.io’s engine will do some caching functions in backend while handling database calls)? If bubble.io will always get a result from the db, that nice function will increase my workload units for that app.
And now let’s come to the point:
Would it make sense, to do something like an “initialization” (init) prozess only once if the app is launching. I could create a “custom state” for the users picture and store the database’s record in that custom state. Then the app should always request/access the value stored in the custom state-variable and not by doing a database query.
(added:) yes, I know: the image wouldn’t be “live” - updated if the image will be changed while the user is navigating through the page and the “init” process wasn’t run again).
What do you think? Makes sense?
Happe x-mas and many thanks again for the great support in this forum!
Would not work as custom state values are reset when a page is loaded or refreshed. If however, you are building a SPA that could work, but wouldn’t be necessary in the case of a SPA.
Bubble does do some cache I believe as I’ve seen posts by Bubble staff speaking to the use of cache for helping in achieving some performance improvements for the platform, but I’m not 100% sure on if this specific use case is an area where the cache that Bubble does would eliminate the call to the server as the new page is loaded.
You might want to reach out to support to get those details as they are usually very helpful in getting engineering to give the low-down on how Bubble is operating behind the scenes.
But, you should use the dynamic expression of current users image instead of do a search for if you are not already using the current users image as the expression to retrieve the image.
Let us know whether Bubble support gets back to you on this. Clarifications on WUs is always appreciated.
If, as @boston85719 said, you are using an image field on the user, I would be surprised if displaying the image on every pageload contributed much to WU.
Behind the scenes, image fields are just textfields which contain the url of the image; its not a very heavy field to download.
Bubble downlods to the page the entirety of the Current user datatype anyways (folloqing privacy rules).
Once the Image url is downloaded to the page, displaying the image is a client side action (no WU consumption)
Assuming the below table is accurate, downloading the image url will always be overshadowed by page load html generation (+ downloading other current user fields)
Its true that it has become more important to keep the user datatype lightweight, as character download can pile up.
I do wonder if SPAs will generally become more WU efficient when compared to multi page apps. If the ‘current user’ is cached, then the above might bot be true, but if it doesnt then the difference can be substantial.
Hi all,
is there a chance to get a valid answer from the bubble support team?
I still need infos about that topic for my app’s architecture.
Best,
jupxi
I got an answer from the bubble team and want to share this info with you:
Thank you for keeping in touch with our team! My name is ***, and I’ll be here to help you.
Based on your question from the forum, it seems that you are looking for clarification on whether retrieving the Current User’s profile picture on every page would use workload units.
The Current User’s data is automatically loaded for each page, so requesting information such as text, addresses, or images from the Current User wouldn’t use any additional workload units. Your app would only use 0.15 Workload Units for each page that is loaded.
That said, if you are retrieving a field from the Current user that is another data type, such as the Current User’s Company (Company being the thing requested), then that would trigger an individual request to retrieve the relevant Company from the database. The workload unit cost of individual requests can vary depending on the amount of data being retrieved.
I recommend checking out the resources listed below for tips on how to optimize your app for workload: