Tbh I’m not sure whether this is a bug or a tip, but… I’ve been populating RGs with either live “Search for” results, or a custom state equal to those same “Search for” results. i.e., to find the right balance between real-time updates and WU.
As part of my testing I noticed the following:
On login, I set my allFoobars custom state to be “Search For” all Foobars in the DB
I set the data source of the RG to be the allFoobars custom state
I then went and changed a value for one of the Foobar items in the DB
Expected behavior → the RG would not reflect the DB update until I had reset the custom state. Observed behavior → the RG updated in real-time, and when I looked at the WU chart, there was a .04 WU Fetching data request.
This suggests that Bubble is sending incremental DB updates to the custom state as they happen (which would be awesome). But… this isn’t behavior that I expected, or that I’ve read about elsewhere. Am I hallucinating? Are others seeing this too? Feedback welcome.
Following up with more details, in case it’s helpful / interesting:
It continues to be true that the custom state delivers real-time, incremental updates for items in the original Search For set
If a brand new item is added, then you do need to refresh the custom state in order for it to appear in the RG
Otherwise, incremental updates are delivered in real-time for existing items
In my case, I believe I’m going to pursue this custom state approach for ongoing updates (daily for existing items), and trigger a refresh if/when the server-side DB changes in size (~once a month).
This means then that if an existing entry is modified to say change the name, that name change is reflected in real time? And when this occurs you are seeing a 0.04 WU charge associated with only updating the search results stored in your custom state and not associated with the actual modify thing action?
This means that any new data entries created are not updated in real time?
Just keep in mind your page is refreshed, and the custom state is reloaded every time a user closes the page and then opens the page again, so everyday, if a user logs in, logs out and closes browser every day, the custom state list of entries will be updated to reflect what is in the database at that time. You as a developer would not need to do anything for this to happen.
Yup, that’s what I’m seeing. Using the name change example → name change of existing entry is updated in real-time, and 0.04 WU charge is specific to updating the search results in the custom state, not the modify thing action.
Yup, confirmed. Anything outside the scope of the original custom state assignment needs the state to be refreshed. I believe this is okay, and possibly ideal in my case because:
I have a fairly steady e-commerce inventory, where the size of DB (ie number of unique items) probably only changes about once every 1-2 months.
Meanwhile, I have a steady stream of small updates to existing items (e.g., inventory sales, holiday discounts, etc.)
My app is available as a PWA, so afaict users’ login expectations are longer vs shorter sessions. (I’m likewise checking “keep the user logged in.”)
Loading the app with “Search for…” as the RG data source is 4X more expensive in terms of WU vs custom states – for the same exact page, even with all the tricks explained elsewhere on the forum.
Anecdotally, the app is also just snappier using this custom state approach
Anyway… I’m still experimenting and exploring, but I’m trending towards custom states at the moment – especially given these new real-time update features.
Depending on the size of that list, and the amount of data you want to display in the initial search results, you may consider using an on page static JSON version of it…this is what I have been exploring for a couple of months now in order to satisfy my need to avoid being charged for WUs to retrieve lots of data fields I do not need (we are charged for each character returned). It is not an approach that is easily applied to all situations, but for me, I have a list of 2,000 static products with some 40 fields, but the search results only need 5 fields displayed. Currently the apps WU metric consumption is 95% attributed to the search of that product list. Putting together the JSON approach, I’m fairly certain at this point will remove all WU charges except the page load.
I have not finalized the approach as of yet, but from my investigation/play so far, it is going to be the way moving forward to reduce considerably WUs for fetching data in certain situations.
