Possible Bubble limitations / dead-ends?

Lack of data consistency in the API Workflows is the biggest issue at the moment IMHO.

You can kick off a workflow and you have no idea what steps will execute and which ones won’t.

6 Likes

Thank you all so much for the feedback, it definitely gives us a lot to think about, bubble being a closed system on top of all this, it seems like the probability of this creating more problems long terms than it solves for us short term is pretty high :unamused:

Mehdi

Yep… I have the same problem… My app has a lot of API Workflow dependency… and I feel that I can’t have my app running until Bubble address that issue.

Could you share more details about the inconsistencies you’re seeing? We use the API a lot ourselves and I don’t believe we’re running into any inconsistencies.

2 Likes

Hey @sridharan.s how are you?

Sure… I can definitely share a few things that we are experience with our Bubble app. The first thing important to notice is that this is a well know issue within Bubble and the team itself already have that on their roadmap:

"Apps bug-free at scale
Workflow consistency when multiple workflows touch the same data at the exact same time"

You can see the reference on Releases | Bubble

You also can find a few comments from @emmanuel around the forum about this issue. Acording to him this is major on their roadmap.

So, in our case we deal with a lot of data that we retrieve from third parties APIs. When we setup a client’s account on Bubble we run a lots of API workflows and over 3.000 external API calls. And they pretty much depend on the result of the first “thing” so they can process the second, third thing and so forth. That’s when our problem starts. Also, we can’t have duplicated entries on our Data Base, but since Bubble is processing the same data (not the same action) multiple times it is common leave behind some data or duplicate the entries.

We are doing a bunch of different things to certify that missing and duplicated data are reduced but it always happen. We are now at a point where we have API Workflows going against our data base regularly looking for missing or duplicated data.

One thing we notice is that these problems start to happen when our application reaches 100% CPU. So, in other words, when you app reaches 100% CPU not only your app gets slower (which is fair I guess) but also depending the operations you are doing (API Workflows in our case) the results are not consistent and you will find problems with your data. I guess my biggest critic here is that API Workflows are asynchronous job, so I wouldn’t mind have them taking longer to be execute but I can’t afford having them being unstable with data processing.

This is an image from our usage capacity in the last 7 days… As you can see is pretty clear when we are adding a client’s account to our app.

Up to this point we have our app ready to go live but we are holding on to Bubble start guaranteeing Workflow consistency, otherwise it will be insane having 60, 100, 500, 3.000 clients running something that isn’t consistent.

You might ask why we don’t increase our Bubble plan to add more processing units… We already tested with over 12 units but our app always reach 100% when we are setting up an account After that we would need less then 5 units to have the app running… So financially it wouldn’t make sense having 14, 18, 20 units that we only need to use two or three times a week.

Also we are moving some of our heavy data (DB Tables with more then 5,000 entries) to an external Data Base where we can handle better that data and reduce those problems.

It would be REALLY nice if Bubble could allow us to add units by the hour automatically when our apps reach 100% capacity.

Not sure if I helped you at all… If you have more questions let me know!!

3 Likes

I also have serious issues with API workflows and performance issues around them. It has become a major roadblock that has kept me from moving forward with my app. You can see more here: Another post about performance issues

2 Likes

Thanks for the added details @scharan. A few related thoughts / insights for you (and the community) in case they’re helpful for anyone:

  • When your app hits 100% it does delay API requests. For many apps this is probably a smart prioritization of resources. For apps that depend on the API being timely, it’s not. Hopefully this is something Bubble will give us more control over down the road.
  • It’s odd to me that hitting 100% would result in duplicate or missing data for you (if you’re not seeing this when it doesn’t hit 100%). Two potential workarounds for you: 1) add the thing to your database before running the API calls that create/edit that thing. This way, the thing is always there and you won’t get different API calls creating it at the same time, 2) if possible, it may help to space out the API calls a bit (i.e., schedule them for 10 seconds or 1 minute apart or something like that) - this would reduce the likelihood 2 APIs collide with data and it’d also help space out the server requests so you’re less likely to hit 100% usage.
  • The issue with workflow inconsistency when multiple workflows touch the same data at the exact same time - I don’t believe this is an API issue per se, but instead an issue of any/all workflows (potentially) colliding when you’re editing the same data through numerous workflows at the same time. Bubble does offer guarantees if you’re running a single workflow (with multiple actions) so long as you’ve set it up appropriately. If you were to run your API calls as 1 workflow, instead of many, that’d likely eliminate this issue (but would mean that if 1 API call failed, the rest of the actions won’t fire - so you’d need a separate solution for that). I’m not 100% sure on this, but it’s my understanding and I believe this is a solution we’ve used in places (although my business partner owns that portion of our app so I could have misunderstood her).
  • I previously asked Bubble for the ability to ramp up/down the number (or size) of servers (e.g., on an hourly basis). This is critical for apps that have usage spikes like ours. My impression was that this isn’t on their roadmap, but I also believe there are enough apps that essentially require this to scale their business that Bubble will eventually need to build it to support power users. This is fairly simple to setup with custom apps in AWS so I can’t imagine it’d be that much work for Bubble. My guess is they’ll build it in the next 6-12 months, but I’m hoping they get to it sooner.
3 Likes

Tks for the reply @sridharan.s

So, about what you mentioned:

  1. About the delay on API calls, that ain’t the problem… We thought that might be the problem as well but we carefully looked at Bubble’s logs and also the external API Logs and we do see that data is returned and Bubble receives the data. We got a few "API Workflow errors"but most of them were problems with our setup. But at this point I can guarantee the problem isn’t with data being returned to Bubble.

  2. We are already doing booth things you mentioned : ). We are avoiding at all costs having data on server RAM so we constantly record data on “Temporary” tables so we can process latter. By the way @Kfawcett, reading your “Another post about performance issues” this is a great tip for you. We are also leaving plenty of “room” between processing things on a list… Some of our items have over 15 seconds difference.

  3. Yeah you’re right, it’s not exclusively about API Workflow but I do think they will address the issues we are currently having when they implement that functionality. About the 1 workflow guarantee, yes I guess you are right, they do offer that… but in my case it would be impossible doing everything I’m doing with only one workflow. Only 1 API workflow is for simple tasks I guess… We do a lot of scheduling API Workflow on a list.

  4. Yeah, My opinion is that they won’t do this any time sooner because they are making more money like it is right now. For example… we are running our app with 7 units… We might have to go up at least to 15units if we wanna take this to production… If that “scale” feature exist, our app would be running we around 3-4 units most of the time… I’m sure most of you feel that way.

A few added thoughts:

  • Have you looked at the Data API instead of running everything on a list? It’s Soooo much faster. Was a complete game changer for us bringing data back into our app. We used to have workflows that’d take several minutes to load 50-100 rows of data and now it’s loaded in a second or so.
  • Agree that allowing temporary boosts to server capacity could appear as if it’s not in their short-term interest, but it’s absolutely in their long-term interest because keeping customers on Bubble is essential for their business model. Plus, they make all of their money on large-scale customers, not small ones, (based on their current pricing model) so it’s absolutely in their financial interests to support power users and keep as many of them as possible using Bubble for as long as possible. I’d also like to add that Josh and Emmanuel are working on a vision much bigger and meaningful than simply creating a business or making some money for themselves - I think they’re working hard to create something that’s truly valuable for people. I can’t imagine them even thinking about making short-sighted decisions for selfish gain at the expense of their customers. Just doesn’t seem to be their approach.
2 Likes

Can you expand on this? I would really like to know how you did this and see if it is something I can integrate into my own app. Screenshots maybe? :slight_smile: Thanks.

@kramwe wrote up a thorough explanation here: How to write data to BubbleDB using Data API Bulk Data Loader

Enjoy!

4 Likes

Hey @sridharan.s

I’m familiar with the Data API. The problem is that we don’t have all the data ready to go. We have to get pieces fromAPI #1 and with that result go to API# 2 and get more data… We hit over 15 different APIs endpoint in order to get all our client’s info. So we do need the logic behind API Workflow, it isn’t just loading the data… At least my understanding of the Data API is that you can read and add data in Bubble’s DB really easy… but not process the data. Am I correct?

Tks!

What do you mean by “prcoess the data”?

Let me try to give you an example… Let’s say my app sells plane tickets for multiple airlines… My client is a company not a regular person. That company has multiple users… Once they register into my system I now have to manage all their current and past travels. So I need to do a couple of things:

  1. Access my client’s account on each of the airline company that I work with (using the airline API to do that)

  2. Pull every user that flew with those companies.

  3. Start creating a centralized “passenger history” on my app so you can type the name of the person and have all his/ hers travel information regardless the airline company.

  4. After I have all the companies passengers/ employees now I need to query the airline’s API and get things like “flying info” ( departure from/ arrived where), “payment history”, “extra purchases” (extra luggage, premium seats etc).

So… this is just a very basic scenario where my data isn’t ready to be loaded in Bubble and I need to orchestrate multiple APIs endpoints in order to build a centralized passenger information. Going back to our main topic that is when things start to get duplicated or missing.

Of course I just gave you a basic example… our actual app runs against 15 different endpoints over 3.000 times to setup 1 account. : )

That’s why I think Data API couldn’t help us… Am I wrong?

I believe the Data API can help with this, but my business partner @kramwe has a much better understanding of the ins and outs of the data API so I’ll let her respond.

1 Like

How about using the Data API to bulk create new records, then do any needed updates / linking via a single recursive scheduled API workflow, which does its own check for more records.

This way, there’d be no issues with multiple writes to the same record.

2 Likes

I’m sorry @mishav I’m no quite following…

How can I “bulk create” new records if for every record I need specific (unique) information from a previous call… Getting the example that I gave above:

  1. Client’s Name: Whatever
  2. Employees: John, Anna, Cris
  3. Airline Companies: Delta, American, Southwest
  4. Origin: MIA, MCO, LAX, LAS
  5. Destination: MIA, MCO, LAX, LAS, LAG, HOS
  6. Cabin Type: Economy, Business, First Class
  7. Ticket Price: $$$

How can I bulk create that? If in order for me to discover how much did the ticket cost I first need to know the Employee Name, Airline Company, Origin, Destination and Cabin Type? I might be able to bulk create the 2nd or 3rd step using bulk create… but the more complex stuff aren’t there.

Am I interpreting Dara API wrong?

By the way… Bubble’s lack of documentation (for advanced stuff) and best practice guide is kinda frustrating.

Yes its tricky!

Imagine this API workflow, scheduled to run with a batch of 10 employees. Another workflow can run in parallel with a different batch, so long as they won’t both try to create or update the same rows, i.e. both attempt to create a cabin type record if it was missing.

Steps, guessing how you are allowed to batch the calls to the airlines …

1 . Set period end-date to now. Retrieve period start date from previous batch’s end-date.

2 . API call to airline 1 submit list of employee ids that match the airline system, query for trip history within period.

3 . Use results of API call to make a Data API bulk create trip history rows.

4 . Use results of Data API call to make further airline or bulk calls or database updates if needed.

5 . Store the period end-date for the batch

If the sequence breaks, you’re left with a batch incomplete, easiest choice is to delete the period’s incomplete trip history and let the next batch run reload it.

It would be interesting if the API workflow is sufficient to handle this complexity.

1 Like

Tks @mishav for the explanation… I’m starting to understand a bit more how I can achieve that using Data API.

One thing that I’m still struggling is this… Today If I wanna create a new thing something on Bubble from a third party I will use the “get data from external API”. So Bubble will do a GET on that external API and now I can (using API Workflow) work with that Data inside Bubble which is basically Bubble doing a POST on its data base.

Now… as far as I understand using the Data API I’ll be responsible to orchestrate the GET from the third party API and then do a POST (create) on Bubble trough Data API. Am I correct? If that’s the case I’ll need to do that programmatically out side Bubble right? If that is correct, can you share with me how are you currently “moving” the data from an external API and then POST that data on Bubble?

Tks!

You know how to ask the difficult questions! : )

Normally yes, this level of manipulation would be outside the scope of API workflow functions, and need an external server to do.

Recently Bubble made server scripts available through plugins, and using this may be enough to get it done. I’m making a huge number of assumptions, there could be issues with each step. If it can’t be done, there is the fallback option of an external server.

Either way, its definitely coding!

3 Likes