DB design for Recipe App - how set quantity values dynamically

Hi All, :wink:

I’m new to the “no code” community and to have started playing around with bubble. I settled on trying to create a simple recipe web app and to put what I’ve been reading/watching in the learning centre into practice.

As a noob, i was hoping someone could point me in the right direction. One main functionality I’d like to have is the ability to adjust the quantities of ingredients dynamically. for instance, where cooking for 8 instead of 2 people would make the quantities of the necessary ingredients increase.

I’ve seen this in action on by our very own @michaelchang5161 's https://yumbook.co/ - very good work indeed.

The forum post “Database Lists, How do I use a list?”

has helped me get to get started so far as building out some custom datatypes and I’ve even managed to link the field “recipeIngredients” as a list of “Ingredients” (a separate custom datatype in itself) and have am able to enter data into this via the method as described in the forum post “This field is a list (multiple entries)”

But I can’t figure out how to implement the quantity element of a recipe within this database structure and I’m worried that the current set up limits me from the overall goal of allowing for dynamic quantities based on servings.

Can someone explain to me where I’m going wrong? :smile:

also I haven’t figured out how i can share my app so others can see what I’ve “developed” so far, any tips on how to do this would be greatly appreciated!

Thanks in advance


Hi @hems - welcome to Bubble! I did a quick little prototype that may help you. Note that the data-structure I created for this proto is not how I would go about doing it in an actual app because a recipe is going to be dynamic in terms of the # of different ingredients. I might have a Data Type of Recipe and another Data Type of Ingredients and a workflow where the User would create n-number of New Ingredients for each Recipe and then add those Ingredients to the Recipe.
Hope it helps you on your Bubble journey

Thanks @nikolai! I thought about structuring my DB in this way but realised early I could run out of ingredient fields very quickly!

Currently the DB is structured in a way where “ingredients” can be added as its own custom data type to the custom data type “Recipe” as a list.

It’s this list I want to be able assign ‘dynamic’ quantities to.

I think i figured out how to share my workings, :smile: see link below.

I’m conscious I have to create a new datatype - but not sure having quantity in a separate table (as a data type) is the most efficient way to go.

Thanks again

Hi @hems - looks like you’re no longer sharing your app…

For Ingredients Data Type, you should be able to add a Quantity field (number) and I’d suggest a Unit-of-Measure field (number) so your User understands the qty field is # of egg, cups of milk, # of tablespoons, etc.

For the “Recipe” Data Type, I’d also have a Quantity field which would be your default # of servings. When your User wants to double, triple, etc the # of servings, they’d input a value at Recipe and then you’d have logic to multiply that # against the Quantities in the list of Ingredients.

Hi nikolai,

Thanks for the coming back to me again, after my last message in the early hours of this morning I went ahead and created Quantity as a custom data type and added the following fields:

  • IngredientQuantity (Ingredient data type)
  • QuantityMeasurement (number)
  • RecipeQuantity (Recipe)
  • unit (text)

my thinking is that this thing (aka table) will link a specific ingredient and its quantity to a specific recipe. In practice I think this approach will mean that there will be plenty of entries that have ingredient type as “egg” for instance (but each specifically related to an individual recipe).

does it make sense or am i added complexity where it isn’t needed?

Not sure how to grant you access again - any ideas?

Were you able to see my app before?



This topic was automatically closed after 70 days. New replies are no longer allowed.