Handling JSON - Am I Missing Something?

Questions
1

Working with JSON in bubble feels so horribly dated and convoluted that I am convinced I’m missing something.

If you don’t want (or have a need) to parse on the backend via API/save to database to use the response in bubble, you’re either stuck with limited plugins, or - in order to handle anything with even the slightest complexity natively on the front end - you have to do something like:

  1. install a toolkit that allows bubble to ingest JS values (e.g. Javascript to Bubble (JS2B))
  2. create individual bubble functions for each element in the json that you want to work with
  3. write Javascript to parse yours JSON elements and assign each one to a function
  4. Concatenate any multidimensional arrays into strings so you can push them to a repeating group as text (e.g. bubble_fn_someFunction(someObject.map(o => ${o.nestedElement1}|${o.nestedElement2}))
  5. Use event triggered workflows for each JS2B to display its value list of concatenated strings to a repeating group
  6. Reparse each string (e.g., split by (|):first item) so you can display the elements from your array in the correct fields on your front end
  7. if you’re working with numbers, convert your strings back to numbers, (too bad if you’re working with most other non-text data types…)

I understand there are plugins to handle JSON, but there’s LOTS of limitations with those, especially handling more complex JSON. And I also understand there are some “tricks” (you can use the bubble App connector pointed at your own app to return data that can be handled within workflows, at a cost of unnecessary added latency & WU, but hey you don’t have to save to the database so that’s good i guess…). But you shouldn’t need “tricks” to do something this rudimentary.

Bottom line is handling JSON in Bubble is definitely cumbersome and the bottom line is anyone newly getting into no code development is going to balk at using a platform where handling the literal most common type of communication between systems is this bulky and unintuitive compared to other available solutions.

Wouldn’t Bubble’s investors want to prioritize removing this barrier to entry given all the competition that’s popped up over the last couple years?

:folded_hands: OR :folded_hands:

Am I just an idiot? Is there something I’ve somehow missed along my last couple years using bubble that is going to make me smack my head in shame for ranting like this? :man_facepalming:

5 Likes
2

Even the ‘natively’ suggestion uses a plugin. I believe the need to handle JSON well is real.

Most all do. I have not found one that does all. I personally do not use very complex JSON, so only nested one level. But for deeper nested JSON there are few plugins that handle it, and usually tradeoff is on the complexity and ease of use, especially for a No Code environment.

I feel like most of what we have to do in Bubble would be a ‘trick’

Yes, it is true you’d need to use the API connector (I’m not sure about those that use the App connector as I’ve never used the app connector before) so as to initialize an API Object that can then be available as a ‘data type’ in Bubble dynamic expressions, I do not believe you need workflows or unnecessary WU. I have a plugin I built, Data Jedi, to handle JSON as API Objects, and it is not using workflows or unnecessary WUs, nor does it add any latency.

With my plugin, you can have the JSON field use a source of various types. Can be from an option set, a custom data type or even a file. It doesn’t require the calling of your Bubble apps api (latency) in order to convert the JSON into the API Objects. The API call initialized in the API connector is just used as the ‘creation of the data type’, but is not using any kind of URL for calling an API.

So it is possible to have an API call in API connector that uses a URL, but it is not for an API endpoint URL, but instead the JSON file URL. So you can save to an option set attribute, or even a custom data type field a file, and use it’s URL as the api call url which is the dynamic expression within the Data Jedi plugin element JSON field value.

In the setup, there are no workflows, so your api objects are available quickly, so if for example you hard code the JSON field value with just static text, it is on the page immediately, but if you fetch from database the api objects stored as a data field, there is a delay no greater than a normal fetch. So, lots of different ways to get the desired data onto the page with no workflows, added latency or WU. In fact, with the Hybrid Data Structure approach of saving API Objects onto custom data type fields, you can reduce the WU cost of fetching data by 95%.

When I finally realized how easy JSON formatting actually is, and understood it for what it is, which is simply text in an organized and rule based format. Learn a few simple rules, and it is so easy to work with. Definitely makes extending your Bubble aps features greater as well.

I started on Bubble without a technical background. I was searching google for ‘how to start a startup as a non technical founder’ as I did not have a coding background to build an app. That is what made a No Code platform attractive to me. And, at that time, and for quite some time after, JSON was very intimidating to me. Was not something that I could easily decipher what it represented. As I became more familiar with Bubble database, JSON became easier to understand as I had some base to compare it to. It was easier to see it as “field_name”: “field_value” once I became accustomed to Bubble database and creating data fields and knowing of the handful of ‘types’ they may be.

I think at the end of the day, Bubble may view JSON as more daunting to their target demographic, which based on Bubble vision of ‘make software development accessible’, might be still, individuals without a coding or technical background. But who knows, maybe they will add some more native features to make handling JSON easier than it already is. They currently have the ‘format as text’ and the ‘formatted-as-json-safe’ operators for use to work with constructing JSON, but not much for saving it, manipulating it or fetch/filtering it.

Not at all. The points and feelings are all very true and real. I experienced them as well. Once I realized how working with JSON and API Objects make a Hybrid Data Structure possible and the WU savings and ways it makes extended features possible, I built my plugin to solve for all the downsides of most other alternative options available.

3 Likes
3

No. The core platform was created pre-AI and hasn’t changed much since then. I’ve said it countless times that Bubble is asleep at the wheel when it comes to actually interfacing with AI (on multiple fronts). I don’t understand their strategy to be honest.

  1. Hook new builders in with AI generation
  2. Said new builders realize working with JSON in Bubble is nasty
  3. New builder moves to [insert any other platform here]

But we are getting a new property editor at least.

2 Likes
4

thanks for the thoughtful response & glad to know I’m not crazy. I’ll check out Data Jedi as well! :slight_smile:

1 Like
5

It is ironic though that Bubble, the app builder that revolves entirely around a JSON-based representation of your app, doesn’t really support native JSON.

7 Likes
6

The app connector also only displays workflows from your main branch, so before you can use it, you have to push something to main then go back and refresh to be able to use it. Super helpful feature.

7

You say ironic, I say “demented.” It’s really kind of maddening.

1 Like
8

People end up paying a lot of money to therapists to deal with the ‘maddening’. Some prefer to take control and use what is available to them in order to not go ‘mad’.

From the Serenity Prayer, from American theologian, Reinhold Niebuhr, which has been altered and adopted by Alcoholics Anonymous to read something like “O God, give us the serenity to accept what cannot be changed, the courage to change what can be changed, and the wisdom to know the one from the other.“, we learn how not to go ‘mad’ about things we deem ‘demented’ as we will have the wisdom to know that we have the power to change it or not.

In this case, of JSON handling and other ‘not available’ features, we know that we can change that as there are tools that allow us to do these things. For me personally, I prefer to give Bubble a chance, and when they fail to follow through, I find a way to get on with what I need to do, so I use my wisdom to know if I can change it myself or not. I suggest all Bubble developers to follow a similar sense of wisdom and use the tools available, or build the tools, or not worry about it and move on.

Quite a few things that Bubble doesn’t support natively, that luckily the plugin marketplace has plugins for it. Things like local storage, IndexDB, file uploaders, robust chart options, I mean the list goes on and on, and fortunately, for most ‘not natively supported features’, the plugin marketplace likely has a plugin for it. And I know, some people prefer to not use plugins for fear of needing to use a service provider for a functionality they otherwise do not have available to them, but at the end of the day, any and every ‘client’ of a Bubble developer is using a service provider for which they are reliant on to get the functionality not available to them, as they may not know how to build the app, so they choose to engage a service provider AKA bubble developer, to build that functionality for them.

2 Likes
9

I’ve increased my JSON use over time, and since doing so have come to rely on some plugins that make my life easier, and developments ‘feel’ viable. I wish Bubble had stronger JSON support out the box, but it doesn’t, it’s limited.

One plugin I use a lot is this: JSON Assistant Plugin | Bubble

For $14 I get a lot of extra freedom, especially with the JSON → Things and Things → JSON. You do have to add some extra API Connector calls for it to work, but they take seconds (faster than you expect) and once done, it adds a lot of scope for working with JSON.

I have no affiliation with with the plugin author.

2 Likes
10

This post hits hard. It’s impossible to do the following in the backend:

  1. parse JSON to get lis

2. run recursive/loop workflow on list

since there’s no option to get “PLUGIN TYPE” as a param type on backend workflows. I’m forced to perform recursive workflows on the front end via custom events (image below)/

This is terrible since if user moves away from page the process will fail.

plugin types
plugin types904×748 40.1 KB

1 Like
11

writing JSON as an expression in workflows is terribly difficult too. Especially when you need to send list of images inside lists of messages to AI.

it’s like 6 layers deep of formatted as text. It’s hard to keep track of what you’re actually writing.

12

If I understand you - I use the JSON Assistant and I can do this in BE workflows. Check it out, $14 to not have your problem is money well spent.

1 Like