Speed issue (relax, it's not another speed thread)

casheets123 · 2020-09-07T20:29:39.464Z

Not looking to start another speed is an issue thread here

Setting up a super basic Like system in a free tier app I’m toying around with, and I’m
running into a speed issue when doing a rather basic search.

When a user clicks the I run a workflow:

Step 1: Make change to Thing’s Likes + 1
Step 2: Create a new thing “Likes”, of type “Thing”

So far so good. no speed issues here. But in order to stop anyone from liking a Thing more than once. I add a “Only when” condition to the workflow. And here I run into issues.

Only when: User is logged in and search for Likes’s Thing’s Unique ID (created by: current user) contains ParentGroups Thing’s Unique ID

The database contains 1 User 2 Thing’s and 1 Likes. But performing this search takes a couple of seconds.

Is this a badly optimized way of doing it? I’ve been doing hundred of searches like this in my paid apps, and never had any 1-2sec loading times for it.

Or is this the expected speed on the Free tier plan? I must confess I’ve never really mucked about with the free tier before, so not sure what to expect. But It’s almost faster for me to have a second browser window and look up if the Like exists or not, I mean, there’s only one entry

deadpoetnsp · 2020-09-07T20:40:04.214Z

Here’s a way that works flawlessly and fast, and doesn’t let anyone like anything more than once. Create a list of users inside the Thing (Liking users). When a user clicks like, if the list doesn’t contain current user, add current user to the list. If the list contains current user, remove the user from the list.

Alternatively, inside current user, create a list of liked things and you can toggle adding it removing the thing from the list.

Or you can do both.

For better efficiency in fetching, you can create things “user details” or “thing details” linked to the respective user or thing and add these lists inside those things. This makes fetching faster (because the user and thing remains lean)

In this way, you don’t need to even set or search for IDs, and it works instantaneously.

My at app is on the lowest paid tier, and my understanding is that it is no different from the free tier in terms of the capacity or speed.

deadpoetnsp · 2020-09-07T20:42:26.132Z

LOL ok I just read your post closer and realized it’s you @casheets123 I’m sure you know everything I said above. Leaving this for future Bubblers.

casheets123 · 2020-09-07T21:02:46.374Z

Thanks @deadpoetnsp

Yeah, that would the best way to do it, with a list of likes on the Thing being liked. That’s how I initially set it up in fact. The reason I created a separate thing called Likes in the end, is to consolidate all likes as a separate thing, because it makes it easier for me to to display a Users’s Likes on their profile page etc. I’m planning on using this for multiple things down the line.

I have the initial Thing as a field under Likes (linked as you say), I just explained it like a clown haha. I’ll re-write it to make it more clear, thanks.

nnich19 · 2020-09-07T21:24:25.010Z

Just spitballin’ here, but you may be performing unnecessary searches since you’re doing the search for Likes’s ID on every item in the RG group.

Instead, I’d maybe do a search for a user’s likes ONCE, then check against that.

Option 1: Set state on page load (or whatever)

State = Search for Likes (created by current user, plus any other search terms that make sense and/or increase efficiency)'s ID
Conditional statement = Only when: User is logged in and State contains parent group’s thing’s ID.

Option 2: Variable RepeatingGroup (I like this so I don’t have to keep resetting a state)

Create a repeatinggroup specifically for holding the user’s likes, give it the same data source as the State in option 1. I usually put these in their own popup so they don’t clutter up the “usable” elements on the page.
Conditional statement = Only when: User is logged in and repeatinggroup x’s things contains parent group’s thing’s ID

This way, you’re checking each item against the user’s entire list of likes, but you’re not pulling the user’s list of likes for each item in the repeatinggroup. This may not improve your speed immediately, but it may scale a bit better if you end up with lots of users with lots of likes.

Edit: yeah, I know. This is essentially a moot point when you have single digit items in the database, so yeah… That part sucks.

casheets123 · 2020-09-07T22:09:37.135Z

I was never a big fan of the hidden RG. It always felt too much of a hack to me haha. But I haven’t thought of it as a way to not perform a search for each cell in a RG. That’s clever.

I set it up, but as you expected there is no immediate speed gains, at least not with the one single item. But if I can’t come up with a way of trimming of that annoying 1sec. I’ll go with the RG for potential scaling performance. Thank you for that! @nnich19

casheets123 · 2020-09-07T22:12:39.648Z

Somewhat interesting observation. It’s a fair bit faster the second time I click the (after it being unliked). Sort of as if Bubble is doing some type of indexing, or saving it to my browser the first time around. That’s brilliant for repeating searches, but for a near once in a lifetime search like clicking like… it potentially slows things down, if that’s the cause of it.

casheets123 · 2020-09-08T17:49:34.793Z

Right, after building this out in multiple ways to test for speed efficiency this seems to be the fastest way of doing it, by far, compared to all other variations I tried. It has more or less removed any lag. I should be able to use a Users Likes in all intended ways down the line, and I don’t need to use hidden RG’s, which I like haha.

I ended up creating Likes as a list field of type Thing, under User. I.e now each user will have their own little library of Likes linked to the Thing. I guess this is sort of like doing a no-search-search in bubbles eyes.

I’m still puzzled as to why the initial search came with such a severe performance hit. But time to move on. There’s probably something going on behind that scenes that makes that particular search extremely slow on the bubble server.

system · 2020-11-16T20:29:40.544Z

This topic was automatically closed after 70 days. New replies are no longer allowed.