After almost finishing my app, I asked gpt best practices to optimise Bubble apps, the answer got me thinking. Basically, GPT says that the best practice to optimise your app and save on WU (Workload units) is:
Do the search once → save it in a custom state → reuse it.
Example: Page load → do a search → put results in a custom state → all conditions, texts, and groups use the state.
This avoids repeating the same DB call.
Can somebody explain why this is best practice? , If you have already built an app using this method, share your thoughts.
My scenario is the following: A gig management tool for designers. I have these DB (Projects, tasks, requests, clients, estimations), my users will have the feature to CRUD, and I have multiple conditionals for OS like status, priority level, price level and rating. Should I use that method?
but I’ve found that the first answer it gives isn’t always the best.
Usually, after a few rounds, I’ll suggest something, and then it says something like, “I like where you’re going with this.” Or some other off-the-wall thing.
So I’ve learned not always to take its first suggestion. But of course, you only know what you know, so sometimes you don’t know what to ask further. The longer you use Bubble, the more you learn, which means the more ways you can ask, I guess.
I don’t know about the custom states method. But there are a ton of posts on the forum about optimizing work units.
There’s also a plugin called ‘Data Jedi’ that you can look into that saves a ton of work units.
Thank you so much for your response! I will 100% check Data Jedi
I completely agree that we should double-check the outcomes from GPT. After watching several YouTube tutorials, including those from the Bubble channel on custom states, I’ve learned that we can “store temporary data on the user’s side.” This means that there will only be one call to the database instead of multiple calls. If the user refreshes the browser, there’s no need for a new call.
My plan is to keep my original settings, duplicate the page, and test the “custom state method” to determine which approach consumes more WU. I believe this will help clarify any doubts I have.
Hi @Ozzie_FL the Data Jedi Plugin can definitely help save tons of WUs for data fetch (95% savings) and for bulk create/update actions (up to 99% savings).
Yes, custom states will hold ‘temporary values’ in that they are temporarily available until the user navigates away from the page or refreshes the page.
There is a need for a new call because the custom state value is lost when the browser is refreshed.
Great idea! More people need to understand and be comfortable with testing things. Best to see first hand exactly what is going on and testing your own hypothesis for your use case.
I’m working on an app with a similar structure. We have requests which we can call leads or inquiries. We have estimations we call proposals. We have projects we call quotes. Tasks and clients are the same.
In my app, the admin can create multiple templates for creating quotes. With a template we call quote template they can take the information from the quote template and the inquiry and can automatically generate multiple quotes to provide the client. They can make changes to these quotes before they are finalized as the final quote/project.
Because the templates have lists of things, like charge items and contract terms, I am able to use Data Jedi to create all those list of things before ever creating the quote template, which saves tons of WUs when it comes to creating database entries.
Your setup might be simpler in terms of what is involved with a project in terms of relations to other data types and lists of things. Even if it is, the Data Jedi plugin has elements like ‘compare two lists’ or ‘compare two things’ to see which data fields are different between two things to determine if you really need to run any action to save any changes, or undo changes (again, all for saving WUs and creating a more efficient app as it doesn’t need to do anything on the server via actions it doesn’t need to do until it is known it is necessary). The Data Jedi plugin also has searchbox and multi select dropdown that make it simple to have type/search/suggest functionality for 0 WUs if you already have the data on the page (I create a spreadsheet, with CRUD operators inside a single reusable element so I already have the data for the spreadsheet which is what is used for the searchbox source).
I would say Data Jedi is definitely something that could be too much for your use case and you may benefit from the simplicity of using custom states. If you want to keep the custom state ‘temporary’ values around longer, look into a free plugin that has Local Storage or Index DB. Data Jedi has Local Storage and will eventually have Index DB, but both of those allow your ‘temporary’ values to persist even after a browser refresh.
Thrilled to get your answer it clarifies my doubts and helps to better understand how to approach this. Right now I’m getting used to Jedi data by reading docs, I’m also going deeper with custom states + local storage.
I discover (as yo mentioned) if user refresh browser there’s a new call to db but, we can control this in bubble by determining either to run an auto call every certain time or :
Refresh cache after create/edit/delete
After any workflow that changes the database, do this:
Run the “FetchClient” custom event again (the one that searches the DB).
Then immediately re-store it in local storage with the same key (client_cache).
Result: The cache and UI are updated instantly.
Cost: 1 small search (minimal WU) only when data actually changes.
If you are doing this, maybe try another approach. Instead of running the fetch custom event of FetchClient, just instead use the existing custom state list (the one set on page load for that first and only fetch from DB), and either add to or remove from that list the ‘thing’ created/deleted/modified from the action that touches the database. Will make it so you do not waste WU by searching again.
If you are using this approach, it is the same basic thing as just setting the datasource as the do a search, which updates only when the database changes. Your approach is just adding extra layers of complexity with the use of custom event for searching, use of custom states and local storage.
It depends on the expected usage of the data. There are so many variables about an app, the users, and the data to determine the best approach.
If you are not concerned with data being created/modified by other users showing up in the data fetch, and only are concerned with the data that is created and modified by the single user, the custom state approach is fine.
I think this implies that @georgecollier feels that taking time to think through, hypothesis, test and confirm outcomes related to WUs is inconsequential for a professional developer who is not paying the fees for the app and are only interested in maximizing their own personal effective hourly rate. It fails to grasp the reality that any professional developer can within a matter of minutes if they have the knowledge, make a simple change to the way a data fetch is performed in order to reduce the WU costs associated.
@georgecollier do you still believe that it takes too much time to reduce WUs?
it clarifies my doubts and helps to better understand how to approach this. Right now I’m getting used to Jedi data by reading docs, I’m also going deeper with custom states + local storage.
Result: The cache and UI are updated instantly.
Basically, the pattern is :