Like the Comment of a Post

Need help Database
1

Hi guys,

I was wondering about the best approach for “Likes” of a Comment of Comments on a Post of Posts :smiley: ,

So here is the scenario:
My app will have posts created by users, each post will have a comments section, and I want my users to be able to reply and like “if they wish to” each comment on that post.

The question:

which approach is better when creating the data structure?

a. Create a data field as “Likes” which is a list of users.
b. Create a data type of “Likes” which has a data field of users and a data field of comments "this will of course be referenced to the comments of the posts.

your help will be highly appreciated.

2

Hello @ahmed.khodeir.87

3

Hi @cmarchan ,

I have visited this post earlier, and basically, it represents option (b.), but what is confusing me is why you made it as Post ID (type text) and User ID (type text)? , why not Post (type Post) and User (type User)? Please correct me if I am wrong.

1 Like
4

as a user and post loads all the data of every user (eg their profile pic, birthdate, list of hobbies) or post whereas the id is just text ie much less data to load.

2 Likes
5

@boston85719

@TipLister nailed it :smiley:

1 Like
6

Wow, didn’t know that we can actually do that, let me test it out today and see how it goes, I will update you or ask for help once I am done, Thanks a million guys!

7

Hi there @TipLister & @cmarchan ,

One more question doesn’t bubble.io only load the unique ids when we use the user as a (user type)? which is basically a text? which means that it loads only text (user id of data type text)? am I getting it wrong?

8

@cmarchan I think @TipLister is providing the same advice you have in the past. I do remember there was a thread we were both part of not too long ago, in which I indicated I’d reach out to Bubble support to get an answer to the question in order to put it to rest. In that thread I posted what Bubble support responded. I will do so here as well. I believe Sergey provided a very insightful post in that thread as well showing actual numbers to back up the concept.

Firstly, the below is the question I posed to Bubble support.

In terms of the amount of data being returned and the potential impacts on the speed of that data retrieval, when a data type that is being searched has related fields on it that relate to other data types, are all of the fields of the related data types being returned and in essence adding to the data ‘load’ which would result in a slower response if compared to simply saving the unique ID of the related data type as a field?

For example, if I have a data type of User and I have a field that is related to a data type of House and the house data type has multiple fields on it, would the search and return of the results be any slower than if I instead on the User data type had a field that was a text field storing the unique ID of the House data type.

Below is the response from Bubble

Thank you very much for your email, that’s a great question! I was able to speak to one of our engineers about this who let me know that we already store the related data type as its unique ID, so making it a text field wouldn’t improve performance.

We only retrieve the nested thing if there are any fields in the nested data type that are being used. So in this example, if there is a text box that says “User’s first name”, we would retrieve the User object only. If it says “User’s House’s address”, then we would retrieve both the User and House object.

So it seems it is not the case that when you have a related type as field that all of the fields of that related type are returned, but it is the case that it is returning only the unique ID of that related type. However, once you request that related type, all the fields are returned. That is basically what Bubble support stated as well as Sergey who provided some insights from browser console with numbers to exemplify how it is working.

So, @ahmed.khodeir.87 consider the insights from Bubble support as omniscient since it is coming ‘from the horses mouth’.

Also, something to consider, every single data type you create has a built in field of ‘Creator’ which is related to the User data type. Bubble is relating to a data type, and not just a text field as a unique ID. I would suspect Bubble would have carefully weighed and considered the option between both approaches, and if it were in fact true that simply having that relation to the actual type caused all fields to be loaded regardless, that they likely wouldn’t have done that since it would have significant performance implications for every app.

Additionally, as Bubble is expressing that moving forward they will continue to focus on improving performance, and one of the ways in which they intend to do so is to expand the cache of data, that using the related type approach is going to continue to be the optimized way of structuring your database.

Consider a hypothetical as well. In the event that you have a data type called ‘Car’ and another called ‘Car Specs’ in which the ‘Car Specs’ has 100 fields on it and the ‘Car’ data type has a field related to ‘Car Specs’, and in the event you want to show a user a repeating group of all cars and perhaps one value from the Car Specs data type, if you have it related, you would in fact be loading all of the 100 fields from Car Specs just to show the one field you want to. So, in this case, it might be wise to put onto the Car data type a field that is a text value that is the single field from Car Specs you wish to show.

Alternatively, doing a related field as a text being the unique ID of car specs, in that repeating group you would need to ‘do a search for car specs’ constrain by the unique id field in the car data type and in the hypothetical of it being in a repeating group, say with 20 cells, you will be performing 20 simultaneous searches (not optimal) and in the results all 100 fields from car specs would be returned from the searches.

You are not getting it wrong. That is what Bubble does.

7 Likes
9

Thanks, @boston85719 for your detailed feedback and simple yet comprehensive guidance!
my research confirms what you have mentioned, which is great, yet that means I will spend more days restructuring my DB :smiley:

Thanks a lot again for you all @boston85719 & @cmarchan & @TipLister, your feedback is highly appreciated! basically, you all are awsome :slight_smile:

1 Like
10

@boston85719

This is a gold nugget of a post!

I appreciate the time you gifted us with researching and taking us through this topic.

I will ensure to incorporate into my projects, and share with other Bubblers, the teachings of this valuable guide going forward!

Thank you! :smiley:

3 Likes
11

hey all, wrote this up to share with Airdev’s partners and thought i’d share here for the community as well. in the video below i demonstrate how you can test and verify this behavior with the Chrome Devtools (or any browser’s developer tools).

one thing to note is that the nested data, if used by the page, will be returned in a separate API call, which isn’t done until after the first search is returned and filtered by client-side filters. when building pages that have lots of data displayed in RGs or which process a lot of data, this is an important consideration, as the nested data + filters can take several seconds to process (or worse) if a lot of data is loaded via this flow, or if there is more than 1 level of nested data.

here’s an explanation demonstrating how to see this in action on a simple page:

Explanation of performance on searches/nested data, devtools demo?

test on this page if you’d like to reproduce it: https://canvas-test-jan-13-2022.bubbleapps.io/version-test/rg_nested_objs?debug_mode=true

4 Likes
12

Hey Chris! Thanks for the video. Very insightful!

Thinking through this … it seems that it is not a straightforward approach to do one or the other (storing a uid text vs an object). Both can work depending on the context.

In a scenario where the separate api call is done … it may be better to store the uid as a text so that only one call is done instead of two.

I can see other considerations taking place as well.

Thanks again! :+1:t2:

13

How would you return the data fields from the data type you are storing the uid of as text? It seems as if you’d have to do a search.

From the video I took away that the storing of any field you would want to display from a related object without having the entire object returned is what you may opt to store as a text, but not the uid of the related object. Similar to my idea from above.

1 Like
14

Hi Boston!

My take is that when objects are super light I can avoid fetching unnecessary data. Yes … multiple searching is performed in an rg … but I can control many aspects of this … thus yielding for overall better UX.