Been working with Bubble Support on a Work Unit question and found out something interesting. I use “Current User” information all over my app, as I bet everyone does. One example is I pass information on the Current User record to tons of SQL Connector calls. I reached out to Bubble Support because I had a very simple call to a MySQL stored procedure that was using 1.19WU. From my understanding, it should have cost about half so I created a bug to get some support. The Bubble Support Engineers (very helpful btw!) pointed out that my input parameters to the SQL Connector call were using information from the Current User Record (i.e. Current User’s email). Turns out EACH of those parameters was using WU’s because it is a “result returned from the database”. I put together a simple test where I created a custom state and then on page load I retrieved the Current User record and stored it in the custom state. Then, when I called the SQL Connector, instead of using Current User’s email, I grabbed the email from the custom state. Lo and behold, it reduced the WU’s from 1.19 down to .89 (over a 16% improvement).
I really don’t want to go through every element and workflow in my app and change the Current User calls to get info from a custom state. It would take me days. But it would save a ton of WU’s. Seems like this should be really simple for Bubble to manage the Current User behind the scenes for us by loading it into client memory at startup so we aren’t hit for WU’s whenever we reference Current User. Not sure how to formally request that.
If you have already put it on Support’s radar (which you have by working with them on it, of course), then you could probably pop it onto the ideaboard, too, and that’s about it.
Current User should not be something we have to pay for each time we reference. As you say it should be pre-loaded and available as long as the user remains logged in…so if they log in and come back two days later without having logged out, that data should still be loaded and not cost us anything to load again.
I think this is a good example of how the new pricing model starts to reduce the number of viable methods to accomplish something. One of the strengths (and weaknesses) of Bubble has been the ability to accomplish something in a number of different ways. As long as it worked, we were happy!
Now, we have to be much more aware of the methods we use to build stuff. I don’t know that it’s a bad thing, just a reality. This particular tidbit of loading the current user into a custom state is an example of something I never would have thought to do, but at scale, can certainly make a difference!
I agree with you for sure, WUs have forced me to be a better Bubbler…but something like this sounds like a bug not a feature.
Bubble already loads the current user into the page so why does it have to do another search for current user when running a front end action? That does not make sense.
100% agree with all comments. If Bubble made this change for us, we would immediately receive a work unit benefit. Easy fix / big impact = please do it now!
The other thing that occurs to me is that if Bubble wants us to tune our apps, I would really like more tools that make the tuning work less cumbersome. I would gladly load the Current User into a custom state at startup and then reference the custom state in my app. Not difficult work at all. But it’s really time consuming because there’s currently no way (that I know of) to tell the Bubble Editor to change all the “Current User’s email” expressions to “custom state’s email”. A Search/Replace feature (that’s available in all code editors) would be really handy.
In defence of Bubble, this sounds like a conservative solution to the “stale cache problem”. A single user is allowed to be logged in to multiple devices. This means that even if you cache the current users data on one device, there would be no guarantees the data has not changed in the database elsewhere, due to another device (e.g. multiple terminals at a single store). As well there are many use cases (e.g. reading blogs) that do not require a logged in user, with a persistent identity in the database. In which case, the current user is a transient or ephemeral store of data, existing mostly in the local cache, not the database. The only way for the Bubble server to know that the current user, from the database, is relevant, is for developers to explicitly reference the database’s current user.
Your very good solution of saving current user to a custom state overcomes the “stale cache problem”, because behind the scenes Bubble subscribes that state to receive real-time push updates through Bubble’s web-socket service. You can observe this in the Chrome Developer Tools under the Network tab and then filtering by WS.
In this case I believe Bubble is in the right, by constraining developers to make a very effective engineering choice. If you want to make your life easier, you can make an invisible reusable element whose only purpose is to maintain and provide current user state. You would then drop that element on every page that needs current user state.
And let’s be honest… change this behavior in our Apps will make thing much more complex. Don’t make any sense have to make our Apps much more complex in order to use less WU.
I keep thinking how many other odd caches like this is hidden in WU consumption behavior…
Thanks, really good points to consider for sure. Question though - if the custom state solution works to keep everything updated and in sync across multiple sessions, then couldn’t Bubble effectively do the same thing for us? Failing that, maybe the it’s best for Bubble to invest in other editor features (e.g. search/replace-like functionality) to make these changes easier. I bet I reference Current User 100’s of times in my app. The thought of spending days manually hunting/changing each of those occurrences in a slow editor makes me want to throw up a little.
Reading this thread, I can also observe those extra workload units for searches that are repeatedly used in an app, especially for reusable elements.
Bubble says that same searches are only triggered once and being cached for use for each session so that it will not interact with the database on every search if it’s already been fetched. However, on my observation, it seems that repeated searches are being charge by workload on each instance no matter if it’s that same search.
Another weird thing that I have observed is that workload units are charged for an action like “make changes to…” even if the “thing” given to that action is empty and hence nothing really happens. Trick to avoid that is to check that thing to be empty each time. In some cases unfortunately, the condition of when to run that action is so complex already, and there are so many steps in workflow that adding this check everywhere becomes cumbersome.
Things like this can have a dramatic effect on how apps are charged WU’s. This one alone could be worth a significant reduction to all apps immediately. I believe Bubble wants to know if there are problems and will fix them, but they need to know if there are problems!
I think they really intend to charge WU for every keystroke in searchbox element.
Here’s a reply from bubble support.
To further elaborate, the search box element will conduct a new database search for each keystroke. Therefore, sometimes it may be more efficient to perform this search client-side instead and use an advanced search to filter the results. I have relayed feedback to our team to update our manual to include this information. I greatly appreciate you reaching out about this! We are always looking for ways to improve so I certainly appreciate you looking for further clarification, as it was not easily found in our documentation.
This would make sense though. Since you’re calling a dynamic search with different constraints and values everytime the searchbox value changes on a keystroke.
Which is why a normal Bubble input element has a delay before updating it’s stored value.
What would suck is if the same search constraints applied to different elements with the same results cost additional WU. Which IMO is a bad practice. Use states, plugins or other elements to store frequently used search results.
Can you suggest a plugin where you can use to make searches global in your app (especially for SPA). This is for SPA that contains several reusable elements as psuedo pages.
Use case:
On the main page, make all the necessary database searches.
On the reusable element, refer to that database search client-side only and filter as needed.
I use the Floppy plugin which has an expression watcher element for storing my loaded values but you can always store loaded values into a state.
The reason I use Floppy’s expression watcher is because it has a nifty event that watches for when it’s values change. This lets me keep things synced and i can build additional UX so the user always knows that something changed or is changing.
When to use states versus searches as a data source depends on your need for realtime updates:
A list of Things in a state will not change without an action (no realtime search WU costs).
A Search For keeps a list of Things updated within it’s search constraints (hence the realtime search WU cost).
