my app shows the user a year calendar. I stored the data for each day in a single record, because every day could have some other infos stored in that record.
If my app starts, the db is requested and I do a search by and store all the data (for one year, eg. 2024) in a custom state. So I created a custom state on page root level with the record type set to the database table. This works fine so far but if there is a lot of usage (traffic) on my app, there would be a heavy database workload (fetch data) to initialise that database call.
So I’m thinking about to don’t use the database for that data, I want to use a custom state instead.
My question(s):
If I create a custom state from a datatype coming from my db, than I can handle the data like a “real” db (table-style and I can access all fields). Is this also possible for custom data structures in the memory (custom states)? Sure, I can create a new custom state “text” and enable “multiple items”, but there I can only store 1 field (n-times).
If I use custom states instead of the database, would this save bubble app’s workload?
Is there maybe a plugin to use the “memory” instead the database?
You can store each row of data as a JSON or some pseudo JSON. So depending on your use case, the state can be a list of texts and each text will be a JSON representing each row of data.
Alternatively you can use a single text state to store an array of JSON. A better alternative if you plan to do any computation of the data collectively.
Depends. You will still have to load the data to create the JSON (or if you store the JSON in a text field in the datatype).
In theory Bubble won’t load data that has already been loaded (note that WU charges still apply for every loaded item that is updated in realtime). So you can take that into account.
You can save costs by reducing realtime updates WU by using API calls to your DB. So you retrieve the JSON instead of the item itself.
There are plugins that can help you write to browser session storage. Or you can store data in “local” and keep data long term, but there’s the additional step of keeping things in sync.
States are good enough IMO. I tried the local storage route but the process became convoluted and affected the UX.
If done right, yes. In theory, browser storage is faster when you are processing large amounts of data but at that point integrating some custom code will be better.
Note that regardless if its a state or otherwise loading large amounts of data at one time WILL slow your app down.
To sum up
If you’re looking to save WU, look at what is costing the most WU along the UX. You can trim it down by reducing “realtime” WU costs, paginating data loads etc.
UX (or speed) can be enhanced in several ways. Use loaders and blockers. Load data in batches (load x amount first then load the rest later). Avoid loading unnecessary data using privacy rules, satellite data or API calls.
Set a baseline by observing your current WU expenditures and where the UX is not up to your standards. Then make improvements in parts.
