Creating entries in database from cells in a repeating group

bek · 2024-12-11T05:36:51.876Z

Each creation is what, 0.5 WU? So ~4WU for creation and deletion.

If 1k WU = $0.30, then one full run costs ~$0.0015

ihsanzainal84 · 2024-12-11T09:44:37.398Z

I know. Pennies. Many a pretty penny.

pieter.vanrensburg · 2024-12-11T10:23:45.456Z

Before the WU based model this was a viable option. In fact, I still use it when I’m absolutely guaranteed those records will be used. However, when we have 100 users each do this 10x per day, you get a cost that most would consider material. Now apply the same coding method in 20-50 other places in your app and it very quickly becomes unprofitable. We should never touch the DB unless we absolutely have to.

shane.holohan1 · 2024-12-11T10:59:40.866Z

I’d suggest that there’s a better solution from both a user perspective and simplifying the WF needed.
As a user it’s more intuitive to add one loan at a time.
User clicks on “Add Loans”
One loan data type is created (can be “draft” as described by @bek )
Loan data type is added to users “Loan List”
First line of RG is then visible (RG dynamically loads all loans in “Loan list”)
Fields in RG autobind on Loan data (or when confirmed by button click)
Then user clicks “add another loan” or “finish”
Add another loan creates a new “loan” and adds loan to “loan list”
When all loans are added, clicking finish changes all loans “draft field” to “no” - using “make changes to a list of things”

boston85719 · 2024-12-11T11:05:51.841Z

Best way to do this is to take the values from the RG cells and translate them into JSON. Can use a paid plugin called JSON assistant to do this (maybe others but I use that one)…then need to setup the API connector to work with bulk update for your data type of Loans…once the user is ready, can send the JSON through the API call to bulk create as many loans as the user created. Costs less than any other method mentioned, and you can allow a user play around with the RG and loans as much as they want without touching the database, and when they are ready, they press submit button and you run the API call.

shane.holohan1 · 2024-12-11T12:50:52.773Z

Just on observation from a non-tech no-coder. I don’t see the point in using JSON and API when there’s a genuinely no-code option. Surely the whole point of Bubble is to only use code-based tools as a last resort? I get that for code-savvy builders there are often easier solutions (for them) using some code. But the downside is that the built in error checker can’t check the code based pieces. For me the robustness of Bubble’s error checking (and prevention) is why I use it.

boston85719 · 2024-12-11T15:32:23.724Z

JSON is text, not code. It’s just simply formatted in a particular way. API is not code it’s using Bubble built in API functionality of every bubble app and the api connector by bubble. Bubble manual explains how to use it very well.

I don’t code. I’m nontechnical also. But ultimately the point of using the text in JSON format and API connector is to build a better, more efficient and lower cost to run application.

hi.luisacosta · 2024-12-11T15:48:01.642Z

Basic JSON & API skills will supercharge anyone’s bubble use! Would 100% recommend.

bek · 2024-12-11T16:11:32.341Z

Kind of a meta ramble, and beating a dead horse here…but its really concerning to see the mental gymnastics made in the sake of saving a few WU (even at scale).

Obviously a side effect of WU introduction and devs wanting to min/max WU usage, but where do we draw the line in building spaghetti code (that takes longer to build and longer to debug later) for the sake of WU?

At what point do we ask “is what I am building profitable via bubble?”

boston85719 · 2024-12-12T03:45:02.152Z

I think you posted in wrong thread. There is an active thread where people are discussing saving WUs and the pricing structure. This thread is about optimal way to get data from RG cells into DB

doublejay · 2024-12-12T05:29:45.008Z

I use the Floppy plugin to store inputed values on page and then pass those on to backend workflow to create DB entries when submitted.

Don’t understand why bubble doesn’t support this natively. Seems like a very common use case.

shane.holohan1 · 2024-12-12T11:20:21.051Z

Code is also just text formatted in a particular way I don’t doubt that JSON and API creates other perhaps more efficient ways to do things. I do this myself (but I’m four years into Bubbling). The big reason not to do that, until you really have the skill to do so, is Bubble’s error checker won’t pick up any resulting bugs. And that is a big issue for people who aren’t long at Bubble.
And for this particular problem I’d humbly suggest that JSON, API and Bulk Data Upload is a sledgehammer to crack a nut.

shane.holohan1 · 2024-12-12T11:31:59.542Z

IMO the reason for this is the fundamental design of Bubble. It’s an existential aspect of the system. The DB is live, in the sense that changes to the data are immediately visible to the user. There’s no getting data from the backend to display in the frontend. So why would you ever want to store data locally when you can immediately save it and have access to that saved data? And run WFs based on changes to the data. For things that don’t need to be saved we have states. Also states for capturing data at a point in time and passing data between elements.

hi.luisacosta · 2024-12-12T15:35:33.647Z

That’s an oversimplification. Yes code is formatted text but with many rules syntax and hidden functions.

JSON is very simple and nothing like coding lol

bek · 2024-12-12T16:08:39.886Z

Nope, posted in right thread.

boston85719 · 2024-12-13T07:48:38.550Z

shane.holohan1:

sledgehammer to crack a nut

I’ve seen others on the forum use this same saying about other things as well…in this case, no it is not. It is more like using a nail gun instead of a hammer, where the nail gun is good to use for all situations, and in those where there are a lot of nails it performs infinitely better than that of a hammer.

shane.holohan1:

The big reason not to do that, until you really have the skill to do so, is Bubble’s error checker won’t pick up any resulting bugs.

No, one reason to do it before you have the skill to do so is to build the skill to do so…you don’t have experience until you have experience. Plus, the error checker in the API connector will alert you to issues when you initialize, and in the logs you will see the error for failed workflows when you run the API call and there is an issue with the setup. Additionally, if using a plugin for JSON the issue checker will alert you to issues and the debugger will alert you to issues as well, just like any other built in functionality from Bubble (API connector) or well built plugin.

shane.holohan1:

So why would you ever want to store data locally when you can immediately save it and have access to that saved data?

So as not to have to pay for WUs when it is not necessary.

shane.holohan1:

For things that don’t need to be saved we have states. Also states for capturing data at a point in time and passing data between elements.

You can do this with storing data locally as well, however, local storage is not lost when the user closes the browser or refreshes, while custom states are…so a good UX would utilize local storage instead of custom states so as to anticipate the potential a user may have computer crash or something else and when they open the app again, you can have them start where they left off, but custom states requires the user to start all over again.

Also, local storage allows data to be passed from page to page while custom states do not.

bek:

Nope, posted in right thread.

bek:

but its really concerning to see the mental gymnastics made in the sake of saving a few WU

Having to think critically is not necessarily mental gymnastics, and in this situation it is not mental gymnastics. Most of the time people on the forum use the phrase mental gymnastics in reference to WUs is in the attempt to understand the costs of things, but not really in attempts to build optimally with WUs in mind.

In the case of the OP request for help regarding creating entries in database from cells in a repeating group, using the approach of JSON and API connector, in some situations may not lead to saving a few WUs. For example, I have a client app, that gets 70,000 - 100,000 visits per month from Google. They have a form to request a quote. That form allows a user to create multiple ‘loads’ in a repeating group, the number of loads is unknown, and so they can create as many as they want, delete them and modify them all without ever touching the database until they are ready to submit their request.

If I didn’t use the JSON and API connector, the client app would have potentially users creating and deleting things in large numbers before the client app could ever potentially monetize that user.

Now, consider a simple scenario, each user creates two entries in RG…if we create each individually in the database, that is two actions of create a new thing, and the creation of a new thing, which is 2.2 WUs plus the cost of characters…for api it is 1.75 WUs…if we think 100,000 users a month, that is 45,000 WUs per month, assuming each user only ever creates two things. Its not a few WUs, and in the end, every little bit matters.

Additionally, it is not just about WUs, its about performance.

At the end of the day, I’m just offering free advice on how to build the OP feature in an optimized way. If others do not want to build optimally, that is there choice.

bek · 2024-12-17T05:18:13.990Z

boston85719:

Now, consider a simple scenario, each user creates two entries in RG…if we create each individually in the database, that is two actions of create a new thing, and the creation of a new thing, which is 2.2 WUs plus the cost of characters…for api it is 1.75 WUs…if we think 100,000 users a month, that is 45,000 WUs per month, assuming each user only ever creates two things. Its not a few WUs, and in the end, every little bit matters.

You’re not wrong regarding what a few WU in savings can impact long term, but my point is based on context of the users question.

If the question was based on the MOST optimal way to do it, then sure, saving every fraction of a WU matters. But here, in the bubble forum for “Need help”, I think its silly to debate impact of saving .5 WU and more so helping a stuck user easily solve their problem, so they can continue learning bubble in hopes of building whatever they are building.

Its like a user asking how to beat level 1 of Mario and people are talking about speed running.

boston85719 · 2024-12-17T06:47:32.779Z

samir.elkaddouri79:

I’m having trouble implementing this functionality. How can I achieve it? Any guidance would be greatly appreciated!

bek:

If the question was based on the MOST optimal way to do it, then sure, saving every fraction of a WU matters. But here, in the bubble forum for “Need help”, I think its silly to debate impact of saving .5 WU and more so helping a stuck user easily solve their problem, so they can continue learning bubble in hopes of building whatever they are building.

You are correct the user didn’t ask for the MOST optimal way, but they did ask for any guidance.

I personally am well aware of how to provide guidance in the forum as I have nearly 15 years experience as an educator. As I was I think the 8th person to provide guidance, I felt it unnecessary to reiterate what others had already showcased as possible, a fully functional approach that very well would have been my own suggestion if not for WUs.

I also know from my own experience how helpful the guidance from experts well beyond my own capabilities had been for me as it caused me to learn something new, thus improving my skill set even further.

bek:

Its like a user asking how to beat level 1 of Mario and people are talking about speed running.

I disagree…it’s like me at age 10 playing basketball against the 15 year olds in my neighborhood. Competing against those at a level much greater than our own, pushes us to get better.

There is nothing wrong with giving advanced level guidance on the forum, especially since it is a public forum, which may allow for other users to find the post and adopt the more advanced level approach.

But yeah, you are correct. Not every user is looking to build optimally, they are just looking to build something that works, and unfortunately, that is exactly why we all are in this WU pricing scheme mess.

ihsanzainal84 · 2024-12-17T08:34:16.998Z

For me it’s about best practices. Optimization should start from simple things. In this case, the solution can be done client side so why spend WU.

It may be pennies now but practices like this when scaled (not just how many users use the feature but in the context of scaling features) will blow up costs unnecessarily.

shane.holohan1 · 2024-12-17T11:41:00.097Z

@boston85719 You clearly have the passion for optimal building and that’s great when it’s what’s needed.
But @samir.elkaddouri79 ‘s question strongly suggests to me that he’s fairly new to Bubble. Most Bubblers are testing ideas or building tools for small scale use and if they’re like me they came to Bubble because of what you can achieve with its core functionality. I would always advocate least code/most core functionality in such a situation. And I’d focus on the user experience first because the user doesnt’ care about WU’s they care that the flow makes sense. When you’ve got a working PoC then you can look at optimisation.
The danger with giving advanced level guidance is that the person attempts something above their ability, fails and gives up. Walk before you run and all that.