Leaving Bubble for more traditional development?

cmarchan · 2020-12-03T03:03:08.054Z

Another option after you exhaust all dB and logic improvements, is to explore a dedicated plan with the Bubble folks @emmanuel . They are there to help apps scale with them. It is the foundation of their business model

chammer · 2020-12-03T03:26:41.991Z

Thanks I’ll check into it

Jici · 2020-12-03T03:32:21.718Z

And I will add this suggestion to the list: don’t hesitate to communicate with plugin author to check if there’s not an option to help you with speed or timed out issue. Don’t forget that a plugin is created using JS and if you replicate this in traditionnal dev, you may just face the same issue. So in most case, there’s some fix to applied to make it work for you

chad · 2020-12-03T08:48:09.592Z

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

nocodeventure · 2020-12-03T09:19:10.653Z

Relational database scheme

oracle.com

What is a relational database?

Learn the definition of a relational database and how it can help your business.

gaimed · 2020-12-03T09:36:38.986Z

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

chad · 2020-12-03T19:02:38.030Z

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

nocodeventure · 2020-12-03T19:17:32.091Z

chad:

Example current users things, things1, things2, field?

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.

cmarchan · 2020-12-03T19:37:05.136Z

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!

boston85719 · 2020-12-03T19:43:54.851Z

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.

boston85719 · 2020-12-03T19:49:05.025Z

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.

cmarchan · 2020-12-03T21:29:13.963Z

Will look forward to it! Thanks for sharing.

chammer · 2020-12-04T00:11:16.656Z

Thank you

chammer · 2020-12-04T00:14:06.899Z

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

ed727 · 2020-12-04T01:58:55.872Z

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.

Alternative approach to the Bubble’s recent tutorials for list of things Tips

Hello everybody, I’ve taken a look at some tutorials from the following topic: In short, I think that these tutorials contain some crucial mistakes. Regarding How To Build A Pinterest Clone Without Code Configure your database User [image] We’re facing this mistake on many apps. That’s a wrong approach since it negatively affects performance and speed. Let me explain why I do think that this is wrong. The Bubble’s unique id for each thing looks like the next one: 1583401182457x36677842…

boston85719 · 2020-12-04T06:41:21.171Z

Thanks for that. Helps explain what is going on.

ed727 · 2020-12-04T14:44:57.209Z

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.

cmarchan · 2020-12-04T14:54:39.583Z

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.

lottemint.md · 2020-12-04T14:57:53.098Z

nocodeventure:

I disagree here, doing a search is much more heavier on Bubble’s side.

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.

nocodeventure:

more heavier on Bubble’s side

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

nocodeventure · 2020-12-25T14:31:00.160Z

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

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.