Is it time to abandon Bubble.io as a solution?

Questions
1

History

I found bubble around the beginning of June when I was searching for an OTS solution for a specialized eCommerce shop. It seemed easy to learn, easy to use if I was willing to give up portability and depend upon a single source provider.

I am more than 7 weeks into this “little” project and have spent the last 3 weeks working through a single problem. Although Bubble really shines in fast UI/UX for simple applications, the lack of the basic logic control structure frustrates me. For/next, Do/While, For/Each and basic recursion. In my case the fatal flaw is recursion. I spend most of my time researching work-arounds on how to do ordinarily simple things so they will work in Bubble.

Scenario

We rent furniture and houseware products in packages. Our product catalog consists of packages AKA kits, bundles or assemblies. A furniture package contains a living room package, a dining room packages and (n) bedroom packages. The contents of each package varies based upon the selected style, number of bedrooms and number of bathrooms. There are 2,992 possible variations of products. I opted for a parent/child structure that limits this to 67 base products and only 3 visible to customers.

Solution

I set up a backend workflow that accepts an order, a product and quantity as parameters. The workflow adds an item to the Order Details thing, calculates discount and extended price then updates the Order with the result of the new Order Details that was created. The next step is to schedule the backend workflow to run recursively for each of the children (sub-products) of the current product. It works up to this point.

Problem

In the backend workflow the order detail items are added to the database. In my test case that is 27 items. However, only 9-15 items are ever added to the parent Order’s Order Detail list element. It isn’t consistent but it always seems the first 1 or 2 levels of recursion get added but semi randomly level 3 and 4 Order Details are not added to the parent group. I can see the order details in the App Data when I display the table, they are just missing from the Order’s detail list.

If I watch the RG during the execution of the workflow, I can see the items being added. Some of the missing items are added then replaced by a different item. No errors appear in the log.

Alternatives

The alternative solutions I see are to write my own API backend to do the heavy lifting and host it somewhere else and then use data API calls back to bubble to access the data (silly) or find a way to use the Run Javascript plugin, and write the code in JS. However, I can’t find any documentation on how to retrieve/update bubble data within the Run Javascript. The only information I have found relates to passing parameters and returning values. I would need to accept parameters, Create Order Details and Update Orders within the Javascript.

The Ask

I hate to throw away weeks of productive work but I cannot keep throwing time down a black hole. Does anyone have any solution they can offer to save this from being a massive waste of time and money?

2 Likes
2

maybe I’m missing it here.

are you trying to apply a discount to a list of object’s price’s and then add those to a single order?

3

Am missing the problem too. How did you end up with a test case of 27 items?

Have you tried using the list processor plugin? [New Plugin] Bdk Utilities

5

Have you gone to Bubble support with this? They may have a solution, or if it’s a bug, they could fix it.

I’m not that experienced with backend worfklows, but 2 things stick in my head: 1) ensuring a specific workflow (like something performed on a list) doesn’t time out; and 2) with a recursive worfklow, adding in a pause before it repeats in order to give the prior task time to complete.

PS: with multi-level parent child structures, I am using them in some subject tags, and note they can be tricky once you start going too deep. I got them to work, but it can take some trial and error.

7

That works if you know how many workflows you are going to start before you start scheduling them. In this case, I don’t know. The workflow decides if there are any children of the current product that need to be processed. You touched on another subject… Not sure how I can tell when all the workflows are finished.

8

@loh.cher.e The workflows ran and added the detail items for 27 items. They just didn’t get added to the order in the next step of the workflow. Step 2 create order detail, Step 3 add the order detail item to the order’s details list. Step 3 fails.

9

@jared.gibb I am adding order detail rows to an existing order. The detail rows contain the product, price, discount, qty and extended price. Those fields get calculated (another work-around) during each execution of the backend workflow. The workflow only processes one product and one detail line item each execution. The work-flow may schedule itself for additional executions if the current workflow product has any sub-products (children)

10

In the backend workflow the order detail items are added to the database .The detail rows contain the product, price, discount, qty and extended price. The order has to exist and the product has to exist before the first workflow is ever started. The workflow is only adding order detail items from an existing product catalog to an existing order.

11

I am sure there a few different ways to do this. For me to tell when one workflow finishes is to add a number to the workflow. So if I am sending a list of items to the backend, I would do a search for the list that I need. Then I would also get the count of that same list. Then on the backend I would send the count and then subtract 1 from each pass it goes through. Loop itself if the number is > 1. When it is 1 then I know it has finished and I can start another workflow when the number = 1. That’s how I can tell when the first workflow is completed before running the second workflow.

I hope that makes sense. :blush:

1 Like
12

Ah yes, the old (as in 5 years old) workflow consistency issue that was on a roadmap and then sort of disappeared.

Add x things to a list in a recursive workflow and you will often get < x in the list at the end.

The workaround is not to do this :slight_smile: - put the parent id on the child. It is a little annoying but at least it works.

Bubble tech are “not aware” that this is still an issue. Which has always been a big worry.

7 Likes
14

This is definitely something Bubble can handle - you’ll find most of your frustrations with Bubble come with the initial learning curve until you really get your head around the Bubble logic - then you realise everything is figure-outable!

Mostly it will be about being clever in database structure - sometimes taking a step back and mapping out your database and workflows on paper can help you find the most straight-forward/simple solution. I think it can be easy to overthink and convolute the process at times :slight_smile:

There’s lots of help on the forum and via google, and I have gotten far by doing that - but I really also advocate for some 1:1 coaching as that can help you overcome the initial ‘bubble logic’ frustrations and get you much further ahead in a short time. Then you have all the foundations you need to figure things out yourself :slight_smile:

4 Likes
15

I will apologize in advance but my frustration manifests itself in cynicism and sarcasm. I will attempt to keep it minimal while trying to reinforce my point.

The workflow is already recursive. I have learned how to make the backend workflows work, but they don’t. I believe the root problem to be what @NigelG pointed out - There is apparently an existing bug in the backend workflow that doesn’t always update lists. The “workaround” for that is don’t do it. Link the detail to the order but not the order to the detail. Driving the invoicing and billing process from the detail items instead of from the orders would be painful to implement.

The data is a linked list so the list does not exist until AFTER the workflow executes. The count through the first pass of the work-flow is always 1. There is nothing to search for to obtain a count before the workflow executes.

If I understand your response correctly, the duct tape, spit and bailing wire work-around idea is to throttle the back-end workflow down to only process 1 item at a time with a mandatory minimum of 1 second delay between each execution (5 seconds recommended). Then, when a product has sub products, simply add more to the FIFO stack and keep processing them using a manually indexed offset, one at a time.

Our users may have a problem with a site that takes 30-50 seconds of delay time + execution time to add an item to an order.

Finally, I addressed the idea of using the Bubble API for an external API that has to be written, hosted, maintained and paid for on another server.

If I choose to go that route, I’m not sure what Bubble is bringing to the table at that point. There is the circular reference back to the title of the post “Is it time to abandon Bubble.io”

1 Like
16

Preach.

I stupidly responded to the wrong comment earlier, without reading the original post. tsk tsk. I’ve removed that post to help you keep things on topic.

At the heart of it, a ‘real’ scripted language seems like the way to go here to manage your FIFO stack and control flow requirements. That may not be what you want to hear, but I think that may be the best option. You are going to find that if you know how to code even just a little bit, it is going to make things so much easier for these types of situations. Complex business logic can live in JS and simpler stuff can live in workflows. Its a little disjointed, but I think a lot of sites are like that (mine is).

I know you can make HTTP requests via a toolbox server script action. Check out context.request() That means you can read and write to the database via the API and parse the JSON that comes back and work and store your objects.

BIG CAVEAT:
I think server-side JS ‘actions’ including toolbox have a 10s execution limitation. Not sure about this. You might find that a simple cloud function or even a turn-key integration like integromat might suffice as well.

1 Like
17

We run recursive workflows that are nested 9 levels deep and create thousands of rows at atime, calling external APIs as they go. No issues with that side of Bubble in 350,000 rows created thus far.

Recusive workflows work, and work well at scale. Passing control records around helps.

You just need to get a bit creative with the “hit this button and wait a bit” functionality.

There is no tool I know of that could do that currently unless you go for a dedicated backend as well, and then you will no doubnt face different issues.

I totally understand the frustration, and as someone who is regularly pushing the limits of platform it am frustrated a lot.

But Bubble’s support is the best it has ever been and there are lots of people who have been where you have been on the forum and on Twitter.

3 Likes
18

See comments above. Code just makes it work in certain way, whereas a mindset change to let Bubble do what it is better at is easier.

Mostly. At the edge there are some deep-seated issues around data consistency on the server.

That said, 25 recursive workflows should and will work.

19

We have a multi level “linked list”.

Each “node” has a control record created for the next level down that has the target and current. The child processes of that node then loop on the values is that control record, updating as they go along.

The child then creates a control record for their child processes etc.

If you search on the forum for recursive workflow then you see a few of us have done this successfully.

The top level product is updated to have a status of “please wait…processing” as this is going on.

1 Like
20

@NigelG My personal experience is that knowing code has actually been a hindrance to learning Bubble. I’m conditioned to think in MVC/MVVC/Functional OOP design patterns that I have to un-learn for this environment.

21

@NigelG This gives me some optimism.

22

Just an update… As per @NigelG suggestion, I removed the order to detail from the backend workflow process. I changed my RG to a search for details->order = parent and added a dirty flag. When the user saves the order with the dirty flag set, it updates the Order->Order Details list with the results of the same query from the RG. It tests successful.

4 Likes
23

Hi Eddie, I think I would focus on the business side and delegate the technical side to a third party expert.