“Individual Data Requests” and huge WU consumption, a method to prevent the problem

Tips
1

Dear Bubblers, I want to share here a method in case anyone stumbles in my same problem.
Around September 10th my app started consuming a huge amount of WUs (6x!!!) without me having apparently made any material change to it and without any change in the number of my users.

My App Metrics showed that more than 90% of the consumption was due to “Individual Data Requests”, an item I had never noticed in previous checks (maybe Bubble changed something?). This post explains what it is about.
It’s a dangerous thing as it does not appear in logs and App Metrics don’t tell what is causing it.

In my case “Current User” has a lot of info attached, including other Data Types, and the page was refreshing such info continuously while the app was being used (Bubble’s websocket is very useful but not when it runs out of control).

After trying different alternatives, I guess I found a good one and my app is back to a decent WU consumption.

Get this great plugin from BDK: UX tools (bdk) Plugin | Bubble. Place element “Screendetect A” on your page.

Create 3 custom WFs:

  • “Update static info”, a set of custom states with info not attached to Current User that you want to be populated only on page load as you don’t need them afterwards (e.g. your logo).
  • “Update realtime info”, a set of custom states with info not attached to Current User that you do want to be always updated when the user is actively using your app.
  • “Freeze realtime info”, a WF that sets to empty the previous custom states.

Make sure that everywhere in your page you never refer to “Current User” but to a custom state named “user”.

On page load:

  • Trigger a loading popup with an element such as Animated Loaders Plugin | Bubble
  • Run “Update static info”
  • Run “Update realtime info”
  • Run a WF that fills custom state “user” with “Current User”.

On “page loaded entirely is yes”:

  • Hide the loading popup

On “Screendetect A goes idle":

  • Show a popup with an hourglass
  • Set custom state “user” to empty
  • Run “Freeze realtime info”

On “Screendetect A wakes up":

  • Hide the popup with an hourglass
  • Run a WF that fills the custom state “user” with “Current User”.
  • Run “Update realtime info”
  • Add a pause of 1 sec
  • Reset groups containing info that were just updated.

Hope this helps!

1 Like
2

The individual data requests for a Thing attached to a user gets called the first time the Thing attached to the user is referenced. Otherwise it is just a UID.

IMO, this is quite a roundabout way of solving the problem of unwanted individual data requests from Current User. Good DB structuring is easier.

  1. Don’t attach datatype fields to User when you can attach User to the datatype instead.
  2. Avoid list fields in User
  3. Use Privacy rules to control data loaded

These can be applied to all datatypes.

2 Likes
3

You are certainly right. If I had to restart building my app from scratch I would certainly structure the database and privacy in a different way. With my current setup, my workaround did its job:

Screenshot 2024-09-17 alle 11.05.42
Screenshot 2024-09-17 alle 11.05.422716×1056 136 KB

1 Like
4

I use Current users Thing’s Field all the time for “cached” duplicate data that I need to display a lot, better than searching especially for heavier data types. #2 and #3 are good ideas.

5

As said, perhaps a round about way to do it.

But still, thanks for sharing. There has been many situations solved with a workaround and this goes in to the pile of ideas.

Best, Peter

6

I have a “Global” datatype that i use for things like that. Since I don’t require all pages to load the data.

7

It’s not a big deal to link a cached Thing with 30 fields on it onto your User type, the only thing linked on the User is a text string (unique id) for lookup. So it’s negligible.

8

Depends on your use case. Since the User data is always loaded.