So I have put so much work into our Google cloud functions, python scripts and other middleware specifically to avoid using bubbler for anything other than UI & a database to keep workload usage/costs low.
Only to find that it’s still using way too many units to be viable for our launch. It appears that even receiving data API calls is incredibly expensive in workload cost. I literally just have my backend function (google shell cloud) api calling the bubble database to pull records yet bubble seems to think this is worth thousands per month (we have just 4 companies/users so far so its unviable to launch or scale with this usage)
So I now have 2 options left:
-
Implement insane caching mechamisms in our GSC stack to ensure we only pull those records occasionally & to bring down how many api calls must be made into the bubble database.
-
Move the whole database off bubble, into bigquery and just start again there.
Why the hell does bubble charge so much just to be a database?! Waste of time building on this platform with that outcome.
It turns out that bubble charges for every received API call and then for EVERY record returned by the API which is ridiculous.
Am I making a mistake with how this is setup or is this literally how it is with bubble even when you strip it right down to just using its database with inbound api calls from somewhere else?
Bubble database is just API calls anyway, so no difference in charges really when you fetch from your bubble DB via an API call or fetching from your Bubble DB via a Do a Search for thing dynamic expression inside a bubble element.
What does the application do that you need to fetch data so often?
Basically this Matt, see below linked examples.
We built cloud functions (coded) which regularly pull all listings from the bubble database to feed web widgets we developed for our partners to place our esim ecommerce experience on any 3rd party website.
I have done some auditing on our stack and can see whats causing the issue so think we can fix this with a bit of optimisation. Pulling thousands of listings from bubble every time a website visitor loads a page was always going to be resource heavy so we implemented a lot of caching to pull that less regularly meaning the widgets then display cached records instead of hitting bubble every time, but seems we made some mistakes there & it’s still pulling from bubble more than intended.
I am about to clean up our tech debt in the stack and ensure it only caches whenever a partner/user updates their listings which I hope will resolve the issue on the bubble workload front.
Example site with widgets: https://airesim.betterconnect.world/ (anything esim related such as plans, popular destinations etc all comes from our widgets)
Another example: Travel eSIMs — Data Plans for 190+ Countries
And a bubble hosted example: www.kwaysim.com
So if we can optimise how often opur function needs to call the bubble data api I think this will eliminate most of this usage on bubbles side (or at least I hope lol)
Any ideas or suggestions welcome, especially from you Matt as your top shelf in bubble development expetise.
Cheers
If I’m reading this right:
Instead of having your Cloud Functions pull data out of Bubble, why don’t you make it so Bubble pushes updates with an outbound webhook only when a record is created or updated?
You could push that updated listing so the widgets load instantly from the cache without ever touching Bubble’s database.
This would save you a ton of Workload Units.
Added: To clarify… You store the widget data in an external database and only use Bubble to update it? You push the data instead of pulling it.
Just a thought.
damn, how many tabs are open
