Save JSON Strings as a List for Saving WU

chris.williamson1996 · 2025-03-21T16:08:57.646Z

JSON is actually a quite useful way to save on WU.

I’ll give you an extreme example of how I’ve recently used it.

We have a client app that does large calculations, we built the calc engine externally due to it needing to run thousands of calculations. Think month by month revenue projection excel sheet but hundreds of things to calculate not just revenue. Since it needs to reference a prior month to calculate the next month you can imagine there would be an insane WU cost with saving all those objects in bubble.

What we did was have the custom built calc engine return arrays inside the JSON of the values, instead of storing objects in bubble now we just store the whole JSON output.

From there we use regex to extract the values as needed from the JSON to display on page or extract data to process workflows on bubbles side.

We went from bubble being completely unviable on a product the client built already to costing next to no WU to run.

tbaohoang94 · 2025-03-21T16:35:41.487Z

I think you didnt read my Post I know that you can do that.

Its about saving WU. Create 2500 Rows = 2500 WU or create single row for 1 WU?

Jici · 2025-03-21T16:41:52.301Z

What I’m suggesting is not to create 2500 rows. Is to store the whole payload in a single fields

Create a DB, add a field, and select the data type of your API Connector in the type dropdown. Use Get data from API t store the whole result of the API call. 1 items. one field. that’s all.
You can use one item for each month and call the previous month item this way that store the previous month data into a single field.

ademiguel · 2025-03-21T16:43:04.646Z

Having to regex a list of JSON text records with 1000-2000 items each can create a very noticeable delay in the frontend, with the consequent degradation in UX.

Having the data properly structured in DB allows for faster searches, especially if they are frequent and table indexes are created internally by Bubble. Also, allows for search constraints, that reduce the number of returned results and so the WU spent.

How you design the system depends on how frequently you expect the user will search through the DB records and how big you expect the table is to become. The bigger the latter two factors, the more reasons you have to save it all structured in DB.

For your particular use case, as you mentioned that the user is performing LinkedIn searches under the hood, it sounds to me like volatile searches, i.e. records consulted once and never again. So, using JSON and regex, as long as you properly handle the search delays in the frontend, sounds like a suitable solution to me.

akamarski · 2025-03-21T16:51:08.857Z

Isn’t still the json response stored? Just it looks visually better and is more usable.

Anytime you do a search which returns this field, you are going to incur the cost of retrieving the characters in it.

Jici · 2025-03-21T16:52:20.269Z

Same thing if you store the whole JSON. And this is a lot less than Create and search for all things you need.

akamarski · 2025-03-21T18:43:46.780Z

Imo Bubble should natively integrate with Supabase to boost their evaluation and get rid of handling postgres entirely,

It will be much cheaper for bubble to exist by itself and we’ll only have a nice frontend and workflow builder.

I’ve moved my app 50% to Supabase and CF workers and my WU are close to zero for otherwise what would cost hundreds of $ per month in native Bubble

tbaohoang94 · 2025-03-21T19:11:05.000Z

Yeah, this I what I mean. You save the whole Json. But if you want to extract the Parameter, you need to extract Them with regex.

tbaohoang94 · 2025-03-21T19:13:07.000Z

I would also love to do that. But supabase is a bit top overwhelming for me right now. Im thinking about shifting to Xano.

But first of all I want to create a Solid userbase, with a Pipeline of Leads before shifting

Jici · 2025-03-21T19:14:19.627Z

No!
You access data exactly the same way that if you was calling API directly
Example: API data’s Created date

Jici · 2025-03-21T19:23:45.920Z

Here’s an example:

screenshot-bubble_io-2025_03_21-15_23_03

screenshot-bubble_io-2025_03_21-15_16_231285×223 17.5 KB

tbaohoang94 · 2025-03-21T19:38:39.000Z

Ah okay, I get what you mean. If I Display data in the frontend calling my own API is the Way to go!

But im Not displaying any data in the frontend anyway but only in the backend

Jici · 2025-03-21T19:45:03.988Z

It does’t change anything. I show you in UI, but you can access data the same way in backend.

davidthorpie · 2025-03-22T14:15:37.869Z

Do exactly this - I switched to Xano for a backend, and it has been a lifesaver. As someone making a B2C app that is yet to go live (this would have happened ~2 years ago, but the pricing changes made this impossible for me, as a self-funded startup).

Use the Xano Connector plugin (or fork it like I did to create more functionality), and do the heavy lifting in Xano. Lambda, map, iterations, conditionals - all the functionality missing from bubble workflows is trivial to achieve in Xano. Best of all - the Xano connector runs client-side in the browser, so the WU cost is trivial! I would still use APIs in workflows for updates though to handle conditionals - and these will still cost, so you should instead have any data changes done on the Xano end. If you have authentication for your app, still use the local bubble DB for “Current User” (e.g. storing session token, and to allow privacy rules) - but use Xano for everything else.

Don’t delay in switching though - converting your workflow logic into Xano APIs is VERY time consuming - my app needed around 60 API endpoints to be created. The resulting performance was incredible though (local Xano server too) - page time loads went down from about 14s (sometimes >70s depending on bubble servers) to <2s. Data refreshes take about 15ms.

With all this said… I have yet to find a better front-end solution to replace bubble, so I believe at this point - bubble + Xano is really the best no/low-code option out there. But with the WU cost model, if you expect to have any amount of non-paying users (e.g. the public) - avoid anything involving bubble database (you can use option sets though, as these are loaded into the page), or server side actions/backend workflows, and minimise the workflows to only client-side functions (e.g. “filter”), and only “Do a search for” on a unique ID (stored in your Xano data) if you need to map something out for the absolute minimum WU cost, since unique ID are indexed in the bubble DB behind the scenes, so are the lowest cost possible.

tbaohoang94 · 2025-03-22T17:21:49.000Z

Thanks for your Input. This is really helpful. I also want to switch the backend as soon as possible. But its time consuming and id like to build Marketing and leadgeneration as soon as possible. I spent half a year Building my App and its frustrating to realize that its not profitable.
I just want to Optimize is to the Point I cant lower the WU consumption. I want to do Marketing now xD
When Im earning a bit id Look for freelancers to help me migrating. Lets See how everything is going.

boston85719 · 2025-03-23T03:27:02.341Z

tbaohoang94:

I just want to Optimize is to the Point I cant lower the WU consumption. I want to do Marketing now xD

Within the next two months I’ll have a free blogging template that uses my new approach to building in Bubble. Some WU savings are insane, but overall, I can do everything for less with my new approach to building.

tbaohoang94 · 2025-03-23T04:19:44.657Z

Awesome! Add me to your newsletter! Id like to get a notification when its out.

tbaohoang94 · 2025-03-23T04:23:35.609Z

Hey. Could you please sho me in detail when you mean? So i have saved this json. Here an example of the First json Object: {“object”:“UserRelation”,“connection_urn”:“urn:li:fsd_connection:ACoAABk77VsB8bsAyRZhZmyWqJS0DDwk3dpnAq4”,“created_at”:1667472279000,“first_name”:“Tobias”,“last_name”:“Schanze”,“member_id”:“ACoAABk77VsB8bsAyRZhZmyWqJS0DDwk3dpnAq4”,“member_urn”:“urn:li:fsd_profile:ACoAABk77VsB8bsAyRZhZmyWqJS0DDwk3dpnAq4”,“headline”:“Fullstack Developer bei Ninjaneers GmbH”,“public_identifier”:“tobias-s-877946b9”,“public_profile_url”:“https://www.linkedin.com/in/tobias-s-877946b9/",“profile_picture_url”:"https://media.licdn.com/dms/image/v2/C4D03AQGYF_CTtQppAQ/profile-displayphoto-shrink_100_100/profile-displayphoto-shrink_100_100/0/1611036381405?e=1748476800&v=beta&t=JZSC9T4kSeQ2tLBJTNZbbc0drwPU5qwKOYE9SxjMKHQ”}

The json is saved in one cell as text type.

Id like to extract the Parameter memberid in the Backend from this String. What i usually do is to use Regex extract: where i get every Parametervalue of memberid.

I didn’t understand your way to call your own API and to get the Parameter. Would be nice, if you could show me a Video how you would do that.

randomanon · 2025-03-23T06:43:20.570Z

boston85719:

Within the next two months I’ll have a free blogging template that uses my new approach to building in Bubble.

davidthorpie · 2025-03-23T12:06:44.643Z

I initially tried this with my app, then realised it was not viable in the long run - mainly because, if I was scaling up the app - it wouldn’t be on bubble, due to the WU pricing model, and the inability to create a “portable” export of my database and workflows. Prior to that pricing model change, I intended on bubble being my primary platform and wasn’t worried about the portability - but the pricing change proved a) I was at the mercy of a 3rd party in determining if my business could survive or not, and b) had no ability to move off the platform if things went south.

All this was the reason I moved to a Xano backend - as it solved all these concerns, as my WUs are now effectively just retrieving static pages, with some occasional queries to the database, thus very little - with the rest of it being driven client-side by a plugin that I wrote the logic in and could extract if needed. If Xano decided to do something damaging to my business, I can export all my APIs (the core logic is mostly in lambdas written in JS) and do a full DB export. Or if I went the other way, I could even go with a dedicated instance of Xano to handle insane scaling. With all of this, if I wanted to start “bubbling” away a build of a new UI in the background on some other platform - I could readily use the Xano backend without any issue whatsoever, so it gives front-end portability too.

So long story short - if I were in your shoes, I would just write the logic you are aiming for in Xano, it will probably save you a ton more pain in the future.