This makes sense but… client side actions still cannot return values.
So my only way to save money is to do the stupid element on the page + exposed state shenanigans…
1 Like
Yeah I’m really tired of the element API for plugins that need no visual element in the page! (Not that it matters with Bubble being 10 - 100x overpriced now.)
2 Likes
I don’t understand why people are trying to come up with client side solutions, even if it does work you can’t trust bubble to not abuse their user base again. Another solution other than bubble is the only answer at this points
8 Likes
In my case, my project uses two api’s and they do most of the heavy work. I’d say roughly 50% of the calls I make can be done on the client side. The rest happen on a weekly basis, once per week (those being user purchases). I think this can work so long as I keep my workflows lean (which I’ve already been doing for a long time)
My request to return results from custom events, client side actions and creating Better Uploader have all been to create a faster system (and now to save money).
I do agree 
that the prices are way out of whack and clearly bubble is exaggerating the amount of user research they really did.
I think the board has lost touch with the average user using no code tools. Sure, my clients are startups with investors backing the project (and even the new prices are cheaper than hiring a bunch of devs) but that’s just a small sliver of who uses bubble.
In reality, they are the minority. Either they’ve lost touch or they are making a business pivot towards people like my client. It would be cool if they owned up to that if that’s the case though
3 Likes
Oh trust, people will do stupid things now like expose private keys, @chris.williamson1996
@jonah.deleseleuc the new pricing is exactly like the previous non-starter pricing. It’s like nobody inside of Bubble understands how Bubble works. Also they seem not to know how the modern web works. You can’t put anything but a modest uplift on outbound API calls or lambdas. And you can’t make any interaction with the db ridiculously overpriced, because that’s like the whole point in Bubble’s current architecture. It’s insane and frankly f**cking stupid.
So exhausted by this.
7 Likes
Additionally: I hadn’t commented on this yet, but consider how stupid it is to now have the recommendation that regular Bubblers “optimize” their apps. First, these people are not web devs and are resistant to becoming web devs. Even though the WU chart is very easy to understand, now there’s all these normal humans asking questions like “why is there capacity usage for some URL that doesn’t exist in my app?” (You know, 404s.)
Second, “optimization” in this sense runs entirely counter to Bubble’s interests. Is the only way you can think of to iterate over a list to toss it into a recursive backend workflow? Why wouldn’t Bubble be happy about that? It consumes cap. Obviously it’s dumb to do that in the first place, but Bubble now has these “specialists” who will help you move that cap off of the Bubble backend.
Why not just have reasonable pricing for that stuff? I’ve already exposed what the markups are and it’s disgusting. Just price things fairly in the first place. FFS.
AND, you know, also fix the client-side iteration issue by implementing a f**cking map function.
I bet you guys here know what I’m going to do to make that issue more urgent.
10 Likes
Exactly, the last few days of figuring out my optimization options has led me down the road of using traditional code methods which while fun to learn new things, goes in the completely opposite direction of why i started using Bubble in the first place.
3 Likes
Yeppers @ihsanzainal84. Another thing that I find wild is that this (the WU chart) allows us to see exactly what Bubble thinks is a cost component of my app and figure out the approximate (or even exact) markup for certain features, even under the current pricing model.
When you look at it this way, apps like my GRUPZ app are apparently wildly profitable under the current model on a pure cost-to-execute model. Obvs, this doesn’t by itself cover things like full-time employees and such, but then supposedly there are millions of apps now. Asking me for an additional $300 a month for that app is ridiculous.
Need to raise the base price to cover all those FTEs and stuff? Sure, here’s $50. Need $100… mmm well I’ll think about it. But don’t build that into my dynamic cap, because I KNOW what it costs for those freaking API calls, or lambda executions or whatever, and there’s only a certain markup that I will ever pay. (And it’s not 4.7 Million percent, ya know?)
6 Likes
It’s funny you say that @keith, one action on our app will end up costing ~3,200 WUs. Ironically, that action is what everyone comes to the app for (the main selling point).
A large app, sure. Running webhooks, API GET and POST requests, custom plugins and various database read/writes. We run consistently <1% capacity.
I haven’t done the actual monetary math, mainly because I don’t want to - but it’s a lot. Our users perform a few thousand of this specific action, per month…
1 Like
That markup is the direct result of the desire for millionaires to become multi millionaires, then eventually billionaires.
Slow, safe and steady growth ain’t an acceptable model in todays get rich quick economy
4 Likes