We have a single-page application with 8–10 navigation tabs, each containing its own repeating group (RG) tables with search, filters, and pagination. The issue we’re facing is very slow load times, usually around 8–10 seconds. If someone can significantly improve the speed, I’ll gladly pay $300 for this challenge.
Details about the application:
SPA with 8–10 tabs/features, each with its own RG table
Multiple conditionals on each RG based on user roles
Using the List Shifter plugin for pagination, but native Bubble “search for” for RG data sources (this could be optimized)
On page load, we’re seeing 10–13 mget or maggregate searches in the network tab
Large and complex SPA with ~50,000 records across a few data types used as data sources (privacy and conditional rules are in place so users only see their own/organization’s records)
This is your problem, no need to use a plug-in for pagination which necessitates downloading all data that could be displayed. Just use items from # and items until # to display the data you want.
If a SPA has 10 list shifters, each tied to its own data type with many items, will all 10 list shifters load all of their data on page load even though they are hidden??
You could check out Data Jedi. It will save you likely more than $300 a month based on the description of your app functions and number of records. It also has a paginator element and searchbox and multidropdown search.
If your app is SPA your initial load time needs to be used to ‘entertain’ the user just like every single large app on the app store does…simple loading screen with animation does the trick.
With Data Jedi and a hybrid data structuring approach you can save 95% on WUs for fetching data, so the costs of returning all data is negligible if you need all data for your apps functionality, and you only want to fetch from the server one time.
If you are experiencing issues with speed between tabs, the issue is likely that you are building reusable elements as the view, and are not able to pass in already returned data, so you end up searching the same data while user tabs.
Not needed, just use one search constraint with ‘ignore empty constraints’ checked. This way it is only one search based on user role to return only the data that user should have access to.
With Hyrbrid data structuring approach you can have a single custom data type, with a field for the organization and than a field that is a list of the api objects. So when a user from a specific organization is using the app, it only fetches the one single custom data type and returns only the api objects belonging to them. Makes privacy a little more robust.
This is again likely caused from building each tab as a reusable element and not being able to pass the values between them, so you download multiple times the same data sets. If you only have a few data types, you should only have a few mget or maggregates, not 10-13.
You can use the items until operator on the search in the list shifter element itself.
I’d also suggest denormalizing (pre-computing in your BE and storing the results) your tables, avoiding reference fetching from other tables, or computing expressions using reference tables.
