i have no idea how Bubble algo in “real-time” syncing database update between client and server(also caching).
My Apps:
A Restaurant Operation App - where the Kitchen display system will show “task list” to process the meal.
in Bubble Database, a data call “task_list” with a field name “linked Restaurant” to differentiate this taskitem belongs to which restaurant.
My Question :
When there is a changes in database “Task List”, the client will trigger sync and update. 2. Imagine, if there is 10 running restaurant, 1 of them have a new “Task_list”, will this actually sync to all Restaurant whose device are reading database “task_list” ( with Do Search for “task List” , Linked Restaurant = Current Restaurant " ?
My Objective:
does the db structure design i use above consider “optimal”?
or actually i have to create a seperate db table for each restaurant?
I assume you’re having a DB that looks like this (which is optimal):
Task (datatype) – old “task_list”
linked Restaurant (field of type Restaurant)
title (field of type text)
Restaurant (datatype)
name (field of type text)
And you’re right you can differentiate between tasks of different restaurants.
Only make sure as you said to always link the restaurant & use that restaurant in a “Do a Search for” constraint.
Regarding your other question:
Yes, the default behaviour inside Bubble is that once you make changes to any data entry (e.g. Task) this will automatically be reflected for the user the Task is displayed to.
I assume that you’d like to make the list of tasks static while a cook is looking at his/her tasks correct w/out updates changing the list correct?
If yes then I’d recommend to create another DB (adding to the two you already have), called Individual Tasks:
Individual Task (datatype)
linked Restaurant (field of type Restaurant)
title (text) <— This text is static meaning not subject to any changes on your Task datatype field “title” (which I assume you have).
You can then always create the whole individual task list on e.g. each order.
You should definitely consider using a seperate DB table for Restaurant, because of performance reasons but also because you might want to save details to it or just that names could be duplicated etc.
my major concern is, performance, and scaling.
which, i am currently afraid of:
1 single update on “Tasklist” will triggered all Restaurant to refresh the data.
as all restaurant reading the same data item “tasklist”
but in thier app-page, i do have this search command like you mentioned:
Do a Search for : “tasklist”
linked Menu = {restaurant} -< another datatype
My next question
Does creating a “seperated” “TaskList” database in bubble will see major decrease in perf impact?
there is only create a new thing, in workflow. there is no “create a new database type” in workflow. does it meant, i have to create a new DB for each restaurant manually?
Well, depends on the number of tasks you want to save, there are differences between 1,000 / 100,000 / 10 mio records.
You will not have to create a new DB for each restaurant (this is why you are using the relationship between task and restaurant in the first place), & if performance slumps in the future you can easily connect Bubble to a different backend service like e.g. Xano as a NoCode Alternative and have your tasks stored there.
Getting to scale a product is the hardest problem to solve & not fighting technical issues that come with it. Actually having scaling issues (talking 100,000’s of users) is a great problem to have as it means what you’re doing works and you can worry about them when they occur.
Most founders waste too much time with architectural nit-picking and don’t use it talking to customers.
If you are planning an MVP you’re right on Bubble, and I encourage you to just build it (especially w/out coding experience) but generally these considerations should come second, first thought is getting your first users or restaurants.
So closing my post, by saying this will definitely be very performant with up to 100,000 records of tasks if not more. So I would not worry too much as you can always move your backend as well as I said.
