Create multiple things, FAST

Hello, bubblers,

I am looking for a way to create multiple items super quickly. My system is a basic form builder that I have built-in my own way.

Each form has a list of field, when I click to create a new entry my workflow creates an entry which has a list of field responses.

  1. Create an entry
  2. Schedule workflow on the list (Create field responses for every field linked to the form)

My problem is if my form has 30 or 40 questions my end users could be waiting many minutes just for their form to load! This is not my expected use case and I cannot accept this.

What options do I have?

So, the standard Bubble approach (what Bubble is designed to do and what Bubble encourages you to do) is to create the Things as you go.

It sounds like you’re doing this already with Entries. Why not just create the Field Response objects as they are created and append them to Form’s Field list as the user creates them in the page?

Apologies, either I misunderstand you or you misunderstand me. This is not when I am “creating” the form but rather submitting an entry to an already created form.

There is no way for me to create as I go because all the questions need to be visible straight away for the submitting user.

Please see an example here:

Are you saving 1 record per response when submitting a form? Do the fields/questions periodically change?

What’s the max questions someone will answer at once?

This is the same issue as when people think it might be better to create a shopping cart that exists entirely in the page and then pass the contents of that cart to the backend and iteratively create the order there. (Rather than create the Order’s Line Items as Things as the user adds them to their cart.)

In some ways, this is smart:

  1. We avoid creating Line Items (or Field Responses or whatever) that later have to be deleted if they are never attached to an Order.

  2. We could potentially (not in vanilla Bubble, mind you) save the user’s cart locally and never interact with the database until the user commits to buying the shit we are trying to sell them.

  3. The in-page experience can potentially be blazingly-fast as we never have to interact with the database. (But, practically speaking, can you REALLY feel the difference between the two methods I demonstrate here?)

HOWEVER, there is no free lunch. If I make some sort of in-page proxy for Things and then send them to a backend workflow after some sort of commit action (e.g., BUY) to turn them into Bubble Things, we’ve delayed our pain. And we’ve traded a few tens of milliseconds per Thing (creating them as we go in the page), for about 1 second per Thing in the API Workflow (AFAICT) on lower-end Bubble plans.

This is fine for shopping cart order submissions (once the user has clicked the “BUY” button, they probably don’t care if they get an email confirmation for several minutes).

But for your use-case, you want your user to be able to click a “PREVIEW” button and see their form in action.

If that’s the case, you just do the calls to Create New Thing (or Make Changes to a Thing) as soon as the user needs them.

1 Like

Hi so some more information on my db structure, I will try to explain simply as I may have over complicated myself.

Admin user will have a “form builder” where they can create the Form and subsequently create any Fields which will be linked up the Form

As a user then I can see all forms and submit an entry. I click the button submit, when I click the button I create an Entry which then has a list field of fieldResponses

So I search for the (essentially static) fields and for each field I create a new data item called response - from there I then auto-bind the inputs value to the relevant value in the form (eg; if type is text then bind the value to “Text”).

If you want to see the editor then I can send privately in DMs.

Thank you for your time so far!

So, you are building something like JotForm?

1 Like

If it’s not a shitload of records, and I’m assuming a form to fill out uses the RG, you could consider using the orchestra plugin to save the records quite a bit quicker.

Or you could construct a json and make a bulk data call to your data api. You’ll get about 10 records per second

Yes, I did create a previous post and I feel like an idiot for making so many posts begging for help but you can see my end goal here.

Thanks, I’ve not heard of either options. Will orchestra help to actually increase the speed at which my items are created as this is where the issue lies because every time I go to submit my form I have to create x number of responsefields.

While not all forms are large some can have easily 30-40 questions which as you can imagine quickly becomes a big wait.

I’m not sure how I’d go about creating a json - I presume there’s some plugin to do that? Then I’d feed that json through the app’s API to create the items quicker if I understand correctly?

Orchestra does not (cannot, in fact) make Thing creation any faster than it already takes when calling Create New Thing from the page. If you think that’s the case, what you are observing is the same thing you will observe if you use List Shifter’s Iterate action to repeatedly fire a workflow that does Create New Thing.

Those individual workflows complete and report that they have completed (via a callback) and List Shifter will continue to the next iteration. HOWEVER, what has happened is that Thing creation IN THE DATABASE is not complete, but from the page’s perspective, it IS complete.

That is, Bubble on the client-side has simply buffered up a bunch of Create New Thing requests that is awaiting completion. If you try to leave the page before all of the new Things have been created, the user will get a warning that it’s unsafe to leave the page.

Several thousand iterations of a Create New Thing workflow can complete in seconds. But those thousands of objects will not be created in the database until the next day. (This is how I create large test databases that I use to benchmark the performance of my plugins.)

NOW, the above being said: I don’t doubt that doing the bulk data call to one’s own API might be (much) more performant than a recursive workflow to create Things in bulk. And I’m going to explore that a bit for the new plugin I’m building.

2 Likes

I’m creating about 375 objects in a dBwith 10 fields in 35 seconds via a bulk data call

2 Likes

This is interesting - I will certainly look at it for sure.

Another option I was looking at would rather than creating the response elements at the start would be rather to display the linked fields with their inputs etc, then somehow get each cell’s inputs value and then when the user hit the final submit button it will then go ahead and create all the items thus reducing the amount of time the user seems to have to wait.

I looked at Orchestra and it does seem to allow referencing of items within a cell but I’m not sure if such a use case is possible?

1 Like

How are you achieving this?

Currently its happening in Firebase. In your case, i’d use List Shifter or Orchestra to create a JSON text body ( 1 object per line) from the data in the RG that has your form and send it to your data api as a bulk call.

Good data point. Thanks @jared.gibb. If, for small numbers (hundreds is small), there’s an order of magnitude improvement in speed of Thing creation, it’s worth the extra setup time and explanation (I’m speaking in reference to my forthcoming plugin for doing shopping cart creation and other object-like manipulations on the client side… It already has one weird action that takes a little extra setup time to rehydrate Things once they’ve been recovered from JSON (client side) and the whole data API thing on the backend wouldn’t be much different).

2 Likes

you could also get really saucy and start saving an entire form response as a single JSON string into a single DB entry and parsing the JSON string when it’s returned to output lists of questions/answers (or however it would work in your case)

3 Likes

Thanks, @jared.gibb @keith for all your help so far. I’ve never even touched JSON in regards to bubble really - especially not converting bubble to JSON. I’m wondering how to even go about this?

Bare in mind that my system runs the API Workflow on List on click of a button, and uses a “Search for” to get the list, no RG is used to create the response items.

If you’re able to point me in the right direction I’ll certainly give it a shot as it sounds promising for sure.

Hi. Thanks for this great thread - @cliffwoodjames , @keith, @jared.gibb!

I’ve built a similar form builder as @cliffwoodjames - but I’m creating the responses as the user interacts with the different fields. In terms of performance there’s no significant delay except for Multichoice questions.

I’ve set them up so that when a user clicks a Question Choice (type) a new Response is created and the Question Choice is added to that Response’s List of Question Choices, the Response is then added to a Custom State with Responses. The data source (.svg icon) of the checkbox icon is switched when each Responses Selected choices contains this choice. No wonder it takes a while for it to react.

I’m trying to figure out a more efficient way to do this or somehow fake it by changing the data src first and then let the workflow run in the background. Not sure if that’s possible. Any ideas?

@cliffwoodjames - I’m also curios to hear what approach you ended up with?

Funny that someone should comment on this thread today. I’ve been working this weekend on a new plugin (as part of Floppy) that helps — pretty substantially — in using the Bulk Create endpoints in one’s app. While it’s cool that that feature exists, it’s inordinately hard to setup and use IMO, for lots of funky reasons (endpoint names completely different from internal Thing names, same with field names). New plugin will make it more suitable for casual/spur of the moment use (though you still have to be mindful of data types you’re sending and such), but you don’t have to set up API calls, it knows how to call your data API automagically… might debut this week.

3 Likes