The Ultimate Guide to Bubble Performance - the new edition is out (now 210 pages!)

Awesome, thanks again :slight_smile:

1 Like

For those who are interested, I’ll be speaking about the book in Zeroqode’s Zero Code Series 1.4 tomorrow (Oct 7th). The event is free, but with limited spots, and you can sign up here.

Time: 10 AM Los Angeles | 1 PM New York | 6 PM London | 7 PM Amsterdam | 11:30 PM Mumbai

1 Like

How download the new version?

Bummed I missed it! Had to work. :frowning:

@yorgio1024
Log in to Gumroad with the same email as you purchased, and go to the Gallery page, you’ll find it there.

Zeroqode will be releasing the talk on Youtube, but not sure exactly when. @ZeroqodeTeam ?

The video is now available here:

UPDATE: there was an error in the original link with the video freezing after about 30 minutes. This new link is working:

5 Likes

@petter Update! My teammate, @matsukana3016 will be reviewing the Japanese translation and she will give you a feedback. :partying_face:

Funny story: She also bought your book long ago (before our company did) and she wasn’t aware of the Japanese translation, she was translating it by herself little by little, as she was trying to read the English pdf. :sweat_smile:

1 Like

That’s great @s.giffard.jp :slight_smile: I look forward to hearing hear feedback! Hopefully it’s not too bad :sweat_smile:

1 Like

Thank you again @petter for this spectacular resource – I continue to appreciate your book as I re-read it. But I’m confused about filtering lists vs searches:

Does a simple :filter operation on a simple list ALWAYS happen client side, or does it / could it happen server side?

As context, here is my use case:

I’m building a rideshare app to instantly match riders with drivers traveling along the same route – the “matching” workflows must occur as quickly as possible, within only a few seconds. So presumably I want these matching workflows to take place on the server, not on the driver’s or rider’s device (even though that will increase my server usage). Certainly I don’t want various actions within the matching workflows to be split between the server and any client’s device, because sending the data back and forth will add time.

In other words, I want the matching workflows to function like this (let me know if you disagree with this approach):

  1. Rider creates a “Check In” thing for a particular Route. The rider may create multiple Check Ins for multiple Routes simultaneously. Each Check In thing in the database includes the Route, date created, and user. Each Check In created by the Rider is also added to that Rider’s list of current Check Ins.
  2. The rider is now waiting for available drivers to Check In. There are no further communications with the Rider’s device until step 4.
  3. Driver Checks In for the same route, and the app executes the matching workflows ON THE SERVER to determine if a match is possible. There should be no communication with rider’s or driver’s device after the driver has created his Check In.
  4. The final step of the server-side matching workflows is to communicate to driver and rider the outcome (match yes or or no) and show messages to the users (via client-side workflows at this point).

These matching workflows include identifying the correct Check Ins for both the driver and rider, and evaluating them concurrently. As noted above, each User includes a list of their current Check Ins. At any given moment, a user may have about 10 active Check Ins on their list – but the total number of Check Ins in the database will be in the thousands.

For the server to quickly perform these matching workflows, I presume it would be fastest to filter the user’s list of ~10 Check Ins by Route – rather than do a search of ~10k Check Ins and constrain by both User and Route.

BUT, does your book state that EVERY “:filter” operation, even a simple one like this, MUST happen client side? Note that this is not a filter on a search, not an Advanced Filter, and not being used in a Repeating Group. Also, note that the other match workflow actions that occur before and after this action are (supposed to be) happening server-side.

Reading text on pages 68, 96-97 and 141-142, it seems like client-side filtering is only applicable to filters performed after a search. But text on 148-150 implies that every filter operator, no matter how simple, must be done client-side. I am confused.

Also, Backend Workflows enable filtering of lists. Backend workflows must be done server-side, so it seems logical that frontend workflows could also be server-side in the right conditions.

Also, if the :sorted operator can be done server side, and the :filter operator can include a :sorted operator in its workflow, again it would appear that the :filter by itself could also be done server side.

Finally, using Chrome console, how could I identify when a list filtering operation is going back and forth between the server and client (and answer my own question :slight_smile: )? Do all those “_ LOOKUP _”'s that I see represent the :filter operators in my workflows going back and forth?

If your answer is yes, and these :filters must always happen client side, then I suppose I will redo my workflows to use searches rather than filtering these lists. But that seems like an inefficient use of server capacity – am I wrong?

Thanks again Petter!

Hey @greg18 ,

Thanks for posting! The difference that you bring up about :filters being performed server-side/client-side was one of the major revisions of the second edition of the book, and if that’s the version you’re referring to it may not be clear enough still (I can’t check the book right now, but thanks for including page numbers).

In the first edition, filters were described as being performed client-side more or less without exception, but it should have been made clear that this will normally only apply to advanced filters (or filters applied to an already completed search). Whenever a :filter is applied to a fresh search Bubble will attempt to perform the full query on the server and in many (probably most) cases it can.

Backend workflows must be done server-side, so it seems logical that frontend workflows could also be server-side in the right conditions.

… so yes, you’re absolutely right about this. For the Chrome devtool question, I’d imagine the easiest way to tell whether Bubble is returning the full list or not (in which the the filter has not been applied on the server) is to check the result of the search in the Network tab. The server never sends more data than its conditions allow, unless it would need some client-side filtering to finish it up.

1 Like

Thanks @petter. Yes I’m reading v2 and was still confused :roll_eyes:

It does seem that my app’s simple filtering is happening server side, I don’t think I see data going back and forth…I just see the data at beginning of workflow, ~5 seconds of no data movement, and then a bunch at the end. So I presume the workflows are happening server side as I desire.

I wish someone would expand upon your description of how to use DevTools for Bubble :wink:. I don’t know of any other resources on that topic. I don’t know what I’m looking at in there.

BTW to add to the filter confusion: you CAN do Advanced Filters on the server, via Backend Workflow. I haven’t tried it, maybe it’s not recommended.

Looking forward to v3 of the book! So much about Bubble is still unwritten…for example you can’t Schedule an API Workflow from inside a Custom Element but the error checker won’t catch it.

I’m grateful for these forums

Hey again @greg18

Sorry for the late reply from my side here - just wanted to let you know that I do want to look into this. Especially your great point about filtering being available in the back-end makes me curious if the book is still not presenting this correctly or at least not telling the full story/covering all scenarios. I discussed this with Bubble’s engineers before the release, but I’m getting the feeling that there’s still some missing info here.

Last weeks have been pretty hectic with completing projects, but would love to continue the conversation when I can catch up a bit. If you learn something new from your research, feel free to share it!

Thanks @petter. Yes let’s please keep researching together! There are many things to discover and document.

I did more testing and learned that my simple filters were indeed being done client side. At first I thought they were server side (per my previous post) but later realized they were much slower on mobile vs desktop – revealing the truth that the filters were being done client side. (If I understood Chrome DevTools better, I likely would have figured that out earlier.)

So then I redid my workflows, replacing :filter with :sorted. Now I am confident those workflows are being done on the server per my intention. My testing of the workflows in a worst-case example consistently took 16 seconds to complete on both mobile and desktop (and when I temporarily “boosted” my Personal plan to Professional, the time decreased to 7 seconds on both mobile and desktop) which seems to indicate server-side workflows.

HOWEVER, once those server side workflows near completion, the server communicates a bunch of data with the client before the workflow completes, which adds a lot of time. I don’t know what is causing this, but it would appear the server is “catching up” the client about everything the server has already analyzed – perhaps to keep the client and server in sync? But this data transfer should not be necessary for the client to function, and the problem is it adds a lot of time. On desktop this processing takes 5 seconds, but on mobile it adds 12, pushing the total mobile workflow time to 28 seconds (or 19 when “boosted”).

So I concluded I should move these workflows to the Backend, to avoid the issue of the server having to “catch up” the client. I spent several hours moving the workflows into the Backend, triggered with a Schedule API at the current time. When I tested that, the Schedule API appeared to run on the FRONTEND on both the server and client!! In DevTools I could see each workflow move back and forth from server to client, even though the Bubble progress bar was not shown (whereas before these workflows happened only on the server, or in my previous iteration, only on the client).

I thought Backend Workflows happened on the Backend?? Needless to say, due to the back and forth data transfer, this was the slowest option tested, taking ~40 seconds to complete on mobile and ~30 seconds on desktop.

So now I’m back to the setup from 3 paragraphs above, a mostly-server-side process with the unfortunate “catching up” communication at the end. Per your tutelage I put a spinner on the page. If it were possible to get rid of the unnecessary “catching up” data transfer, that would save me 12 seconds.

I would very much appreciate your help in figuring out what is going on and if that catching up step is necessary or could be avoided.

I’ll send you DM

1 Like

Interesting posts. Is it possible to get rid of the :filter altogether and do the search wholly in the “search for” box. I can’t grasp exactly how your matching and workflows are set up, but if the search is only based on matching routes, my gut says that searching the Check Ins database and keeping it strictly server side would be faster than digging through a lot of users’ lists and resorting to client-side stuff.

As for the funky stuff you’re seeing in chrome dev tools – also try shooting a note to Bubble support and see what they say.

Hi @petter, in rereading your book you mention on page 151 “There’s no upper limit on how many records Bubble can search through and retrieve.”

However I found this 2017 post referencing a limit of 50,000 search items returned. I can’t find any other documentation about this 50,000 limit.

Could you please confirm that sometime after 2017 the 50,000 search limit was removed and is no longer applicable?

Thank you!

1 Like

Hi @greg18,

The sentence was meant to describe how much data you can potentially search through successfully on the server, and not how much can actually be returned as a result. The sentence you’re referring to definitely fails to make that clear, so I’ll make it a priority to correct it.

Regarding the 50,000 record limit, there’s no reason to think as of now that it has been removed - I haven’t heard anything about it and haven’t been able to find any indication of it. I’ve reached out to Bubble to see if we can get an update on that.

It also should definitely be mentioned in the book, so thanks for bringing it up.

4 Likes

Thanks Petter. I asked in the context of doing recursive workflows on hundreds of thousands of things.

I believe your great recursive tutorial would not work with over 10,000 things to process recursively, right? So I’m building a “batch processor” using a Date Processed field, with repeated searches and processing in batches until every thing’s Date Processed is up to date – no lists.

Might be worth mentioning the 10k limit when you update your tutorial. Thank you for putting together so much great info!

1 Like

Hello, a new bubbler here!
Does this book still cover things in May 2022 ?
Definitely want to buy and read the book for my Bubble project, yet worried if things are not applied to current version of Bubble in any case Bubble has changed from the back then.
Any comment would be appreciated!

Hey!

I’ve tried to take a general and theoretical approach to most of its topics (as opposed to specific tutorials etc), so I think it’s still relevant for Bubble’s current iteration as the fundamental structure hasn’t really changed.

I’ll leave it up to readers to agree or disagree with that :slight_smile:

3 Likes

Very much still as relevant as when it was first released. It’s a must read for anyone building with bubble.

3 Likes