@miguel we are sorry if our response appeared as a pushback. It was not meant to be so. From your multiple reachouts, it appears that your timeline for this feature is immediate. We believe in being transparent and don’t want to promise a feature request that is not feasible within the timeline. Building and using those plugins are free so with the help from the community and some experimentation, you should have a working solution.
I’m on a dedicated plan (not australia) and I will say that I’m very happy with this investment. I love bubble because of it. When you consider what your getting for even just a basic plan, it’s a steal at the price!
- Unlimited apps on your dedicated server (as memory permits)
- Updates (controlled updates)
- Faster UI / Editor (Big relief)
- Faster front end for customers (and auto-bind) / great customer experience
- Prioritized support from bubble team
- Security / 24/7 monitoring
Everything runs a lot faster (even the editor) and I don’t experience the same issues as the cluster, I find i’m well insulated from all that noise. I’ve never had an issue where my front end has gone down and my customers have not been able to access my services.
When I have a system questions or a potential bug concern, I fill out the form and always hear back from someone within a short period of time. The ticket gets sent to the excellent bubble team and escalated to the appropriate individual. I even heard back from @emmanuel once! They work hard to solve the problem. A couple times it took them a few days to push out a patch, but this is very reasonable.
Now, we can’t abuse the bubble support team as they are a small, but growing, team that is dealing with a lot. On the dedicated plan, you will get a response a lot faster that any other plan. However, I reserve them for system related issues and not programming / development related issues. For programming / development, reach out to gurus like @romanmg ( https://coachingnocodeapps.com/) or @copilot ( www.cobubble.com) for help. They are both experts with bubble. Also search hard in the forum as a lot of my questions have been solved.
In the end, if you want performance, get out your wallet and rent a basic dedicated server. It will make a world of a difference in bubble. Even just try it out for a few months to see if it meets your expectations.
I’m really impressed with bubble, the bubble team, the plugin community, and the high level roadmap that bubble is working on.
@gilles, I’m also a huge fan of Bubble and think it provides great value as well.
I do want to add an alternative point of view to something you said though. We’re on a dedicated server as well and I’d say unless a person’s app is getting too much traffic for their server size then moving to a dedicated server makes no difference in terms of performance (there are other advantages as you’ve laid out though).
Here’s a bit more detail, especially for anyone trying to understand whether upgrading to a dedicated server will improve your site’s performance. I’d recommend thinking of servers like a pipe (and larger servers are simply larger pipes) while the traffic to your site is water in this analogy. So, if you have just a bit of traffic (i.e., water going through the pipe) then getting a bigger pipe isn’t going to make the water move faster. But, if you have more water trying to go through a tiny pipe than the pipe can handle, then a larger pipe will make a world of difference.
Also, @michaelm if you’re looking to make page transition times lightning fast then you probably want to build you app using a single page app concept. This makes it a bit slower to load the first page but much faster between pages - very similar to desktop or mobile app. And, sub 1-second times are common for transitions between “pages” when designed this way.
I’d also recommend you check out using Algolia for searches and loading data in repeating groups. It’s incredibly fast (loads huge RGs in ~10 milliseconds), and much much cheaper than building your entire app from scratch with custom code. (more details here - link updated).
Did Algolia solve the problems you were hoping it would?
I read somewhere, can’t remember where, that a filter can be less performant that a query (a Do a search) because the former needs to fetch all the items and then filter them, whereas the latter would perform the filtering on the database. Is this correct?
So, wouldn’t it be great if we could search by unique_id in a list of values, instead of just unique_id = a value?
This way, we could still store a list of unique_ids pointing to Things in a different table, but we could do filtering of those things using a Do a search (using the unique_ids stored, plus other filtering) on the database, rather than get all the things, and then do a filtering.
Does this make sense?
I read somewhere, can’t remember where, that a filter can be less performant that a query (a Do a search ) because the former needs to fetch all the items and then filter them, whereas the latter would perform the filtering on the database. Is this correct?
That is correct, according to Josh commenting it here:
I have been using bubble for about 6months now and I agree that despite the claims from Bubble speed has been addressed, it has not!! It is slow, cumbersome, inefficient and unreliable. I really want to stay with the platform but the lack of transparency over the performance issues really worries me. I just don’t understand why they haven’t been given the highest possible priority.
My current view is that the platform seems to only be suitable for tinkering hobbyist’s projects, certainly not ecommerce professionals that need reliability and speed (just average speed not turtle speed). It’s really disappointing.
Let’s see your project.
I have 3 projects
Let’s see the slow one.
Srsly trying to help you here.
They’re all slow and documented throughout the forum.
No linky. No helpy. C’mon, bro. You know what I do right?
I appreciate that Keith, will need to recreate as I have created API workflows, recursive workflows, custom states, and deleted them all because they dont work reliably. Honestly it’s not any of the combinations of workflows that are the issue here, it is the well documented underperformance of the bubble platform. For example API workflows need at least 2 seconds in between to copy elements of a simple list and often if you have 4 in one list you end up with 3, 2 or 1 in the other list - thats just one example. I’ve posted and documented the issues I’ve been having will add them below in a minute…
Also here is a link to the demo app I set up: https://bubble.io/page?name=index&id=carttest&tab=tabs-1&subtab=App%20Data
Ah actually you created List Popper, right? I watched the video - nice work and nice list of products, I’ll take 1 x “party in a can” please!!
Although list popper and list shifter etc look great t’s going to make hard work of all the information I am taking from a product to a line item to a cart to an order. I need to track abandoned carts, I am adding complex discounts (%, amounts, buy one get one free, or a discount on the second one of any product etc etc)
I’ve just made one of my main projects view only - it works the “bubble way” but slow and unreliable.
So, I don’t see a performance issue here. What I see is that you want to preserve the price paid (for example) of a Product that is thrown into the cart and purchased. (Which is, as it should be.)
In that case, don’t put the PRODUCT in the line item. Put a proxy for the product in the line item. (To be clear: You’re going to put the PRODUCT there too, but you’re also going to copy its fields (at least the ones you care about, like PRICE – which should become price paid). Your scenario for deleting a Product is not realistic. If you want Products to be persistent (that is, let’s say you have a vendor that offers “Canned Cat” and then, “Canned Cat” becomes unavailable due to… how shall we say… regulatory concerns…). Well, DON’T LET PRODUCTS EVER BE DELETED. You instead make them UNAVAILABLE FOR PURCHASE.
So, a line item now is this:
A Product (which has a bunch of fields like “Price” – price is a transient value that might change over time – while that’s all very interesting, we don’t care about that – let’s just let it be… A Product’s Price means “the price this item costs RIGHT NOW”).
A quantity, which is a scalar value that shall never change (“User X bought 6 Canned Cat in this particular order”).
A price paid – a scalar value that is the price User X paid at the moment they purchased. We can call it “Price”, but don’t get confused about this… A Line Item’s Price simply represents a different thing than Product’s Price, eh? (It’s the price PAID.) When we build the line item, we grab Canned Cat’s Price and shove that into the Line Item’s Price. Now, you see, the price paid (Line Item’s Price) and Product’s Price are no longer linked.
A subtotal… maybe. Should we compute that in the page? Should we put that on the line item? Well, we can, but we don’t need to. This is a derived value that we can always reconstruct IF we store the Line Item’s Price (obviously, if we look at a past order, our subtotal can be incorrect if we are looking at Product’s Price (the transient, current pricing) instead of Line Item’s Price (the price paid).
None of the above has ANYTHING to do with Bubble. It’s all “app design shit” as I like to say. Your explainer video – WHICH IS AWESOME, BTW, and I wish I had your accent! – has the answer staring you in the face the whole time… “Simply do change how you are doing it.”
You may have seen this, but I do a lot of talking about carts and such in this video (which is about List Shifter, but covers these same points):
So, not to be a party pooper, but show me an example of poor performance. (Performance means “the absolute time it takes to execute some particular function”, not “I’ve not figured this out.”)
Thanks for that Keith! I think the answer (which was not what I wanted to hear) is that I have to copy fields from one item into another. The issue with that for me is that I thought it would be possible to disconnect an object and keep its data without changes earlier down the line making a change to the final result containing all of the nested data. At the end of the day I am trying to design something that will not lose its data in a catastrophic event - such as a rogue staff member getting access and deleting items - it does happen! Or a more likley scenario of me inadvertantly unlocking access to a field that is subsequently modified somewhere and updated all the previous orders/transactions. I haven’t sent you the example where a scheduled API was copying line items from the cart into an order but it was incredibly slow and unreliable so I gave up and deleted it.
In order to be completely safe I am going to take the contents of the final order and send them into a read only google sheets so that if there was any disaster I have a record of everything outside bubble.
So you think I should use list shifter to take the “Proxy Cart” and move the contents into a “final order”? Or can I do it without?
Aside about “unavailable” Product status: A common design pattern for this is the concept of “Archived” items. Consider:
If “Canned Cat” becomes unavailable for the forseeable future, we may wish to DELETE/REMOVE “Canned Cat” as a product. But let’s not DELETE it. Let’s instead, convert the “Canned Cat” Product into a DIFFERENT data type.
This data type might be called an ARCHIVED Product. What is an Archived Product? It’s actually identical to a Product, but is simply another data type.
So, if we wish to Archive a product, we:
Create a new Archived Product (we could, in fact, create any Archived Thing, right?).
Set the fields of the Archived Product to be identical to the fields of the original thing. (We will want to do some “fancy” stuff like make a field called “original create date” and shove the original Product’s created date in there, as the Archived Product’s Created Date represents the date that we ARCHIVED the Product, not the date the the original product was created, etc.).
Having built a proxy item from which we can reconstruct (more or less) the original item should we wish to resurrect it from the dead, we can NOW delete the original Product. Now “Canned Cat” is no longer a Product and can, no longer, ever appear in any search, etc. But we could reconstitute the original Product, should it become available again (from the Archived Product).
One obvious difficulty: If you store a Product in a line item and then later ARCHIVE the Product, that Line Item’s Product is now gone. What do we do in that case? (Well, we’d have to handle that differently. I go back to my original suggestion of simply not letting Products EVER be deleted, but instead go to an unavailable status, for small databases. But of course there are ways of handling this – it would probably involve having a separate database object that proxies Products that have been Archived and provides a pointer to the Archived version.)
Yep I get that Keith and appreciate your time on this. You asked me if I knew what you do - apart from making dogs and cats in a can I don’t know, are you a bubble shareholder?