Leaving Bubble for more traditional development?

Can you explain this a bit more… how do you not ever do a search?

Relational database scheme

1 Like

We added pusher.js to solve nr 2 (websockets). And we have events that trigger and do stuff realtime.

2 Likes

Thanks I understand relational databases.
I was just wondering what that looked like in bubble.
Are you using joining tables then having a path from the current user

Example current users things, things1, things2, field?

As opposed to having current user saved in things2 and doing a search
Example do a search for things 2 where user = current user.
I would have thought the second example was a better method as your not loading unnessesary things haha

Yep, but you will also need to connect back to User on each thing, that way you can do a lot of cool stuff with the data. :wink:

So … if I understand correctly … in your apps any “thing” has a user single record to it other than the “created by”.

… If so … it is difficult for me to visualize different types of apps where all things in the dB can have this setup. … Well … that is just me! :+1:

Do you find doing a search for a user becomes very slow? I was under the assumption that when creating a relation on one thing of another type, when searching for that one thing all the data from the other type is having to be loaded as well.

So for example, if the user has a related list of jobs and the jobs type has a list of images, when you search for the user, the list of jobs is getting loaded as well as the list of images on each job in the list.

I was doing some tests a while back for performance in terms of utilizing related data types or doing a search…for some instances it was faster to do the search than to rely on the related data types.

The reason for the test was I found loading a list of users became slow when I related a data type of ‘analytics’…trying to fetch the analytics by doing a search for analytics constrained by a text field of the users unique id fetched the analytics just as fast as using a related data type of and doing current users list of analytics; the end result was when I searched for a user it was faster as there was no related data type of analytics.

I’d be very interested in checking out the course if part of it is demonstrating the different methods and the differences in performance…that will make it really beneficial in understanding some best practices.

2 Likes

Will look forward to it! Thanks for sharing.

Thank you :grinning:

1 Like

Ohhh now we’re on to something…Thank you!

I think this post addresses your question. The poster says when you relate a data type, the parent record picks up the ID of the related record. That ID field isn’t data heavy, but if you have a lot of related records, then it adds up. I think that’s also why Bubble says that a list field containing related records shouldn’t contain too many, otherwise it impacts performance.

1 Like

Thanks for that. Helps explain what is going on.

The way I understand it is the optimal direction of linking depends on the nature of the data, how you need to search it, and how you need to display it. This could call for linking data one way, the other way, or both ways (or neither, using an intersection table, which can be a bit of a nightmare, but let’s not go down that rabbit hole…).

So for example if we have an app with dog owners (“Owners”) and dogs (“Dogs”), if the Owners were regular people, they may only have a few Dogs. And if you wanted to show RGs of Owners and their Dogs, then having Dogs within a list field for each Owner would make sense. That way the RG doesn’t have to do a “do a search for” for each Owner in order to show the Dogs in each RG’s cell.

But if that app was a directory of dog breeders, and each Owner has thousands of Dogs, then the approach changes. App users would be searching the Owners datatype (ie breeders) based on things like location, pricing, dog types, years in business, etc. The RG of results would list the Owners, but would not include the Dogs of each Owner (Dogs would only be listed in a details panel for a specific Owner). If each Owner record had thousands of Dogs attached to it within a list field, then the Owner records becomes very data heavy, which slows down the search and display process. And because there is no need to list an Owner’s Dogs within the results RG, there isn’t any speed benefit from having those dogs in a list field in the Owner record.

This is the way I understand this. And corroborates the post’s creator dB structure method
@lottemint.md Alternative approach to the Bubble’s recent tutorials for list of things

On the other hand … I have apps with bidirectional inverse linking that work very fast. Though their dB is rather small so I cannot confirm first-hand @nocodeventure method. But … I built them that way because it felt intuitively right … and yes … my app flows do get longer bc of this.

Prove it with a case where you have 1K+ records. Even with 500 records without lags, and where it will work well on a mobile device.

Before writing this, please check the Network tab to compare.

3 Likes

Hi Everyone,

Coming back on @lottemint.md reply, I wanted to clarify something on my side. I just encountered huge performance issues by having a very large record inside a Client record, causing the entire client page to be slow and querying really slow.

I switched to Do a search for Billing Records, instead of Current Page’s Client Billing Records, the billing records has 11,000 records in it.

Targetting current user took about 2/3 minutes, doing a search for took me about 1/2 seconds with extended vertical scrolling :axe:

From now on the best method will be to do a search for very big lists of data while at the same time targetting Current User’s data only when that data is not a list. Also inside each data table, I will remove all association to the data type Billing record to avoid performance issue.

@lottemint.md Thanks man, you were a hundred percent right and I was wrong on this. Strangely enough, I tried to replicate this on another app with a lot more records and haven’t seen any issues. I guess it’s becaused I’ve stacked Billing record inside multiple data types, causing a major pile of data loaded on the page.

4 Likes

Why more traditional?

I don’t understand the criticism towards Bubble. Even traditional dev tools/editors are unstable For example Xcode is super unstable and slow and it is powered by the richest company in the world). Bubble editor is way better.

I like the car analogy:
Traditional development can have two outcomes: 1) a red Ferrari or 2) a custom car that looks awful

Bubble is like a reliable and cheaper Toyota that takes to you to the same destination.

1 Like

@gaimed could you please clarify and elaborate this one more?

I have been facing issues on realtime updates on RG similar to OPs and many other threads that I saw. Posted threads on it, but no replies. I spoke to a techie friend of mine and he alluded to a possibility of websockets being dropped/closed which also causes the cache of queries to fail as well. So I have been looking for some method that will solve the websocket issue.