To me, this is the point where many people leave Bubbl . custom Work Units. They need to rethink this to keep supporting larger apps and to attract new users who are worried about costs scaling up rapidly.
is each user at table on separate device? Is kitchen opening app and reloading data for each order? Servers opening and reloading for each order? Was there some verification step after 4 guests submit and kitchen receives and server notified before order confirmed? Was bill preparation needing to do data fetching?
200 WUs for the functions seems steep. I’d reckon should be at most 10% of that.
But as long as you’ve got it functioning and find the WU consumption now satisfactory, that’s all that counts and no reason to learn how to build optimally. But, do keep in mind, WU costs are not necessarily just a reflection of Bubble as a platform, it’s more how app was built. I’ve seen some horror shows recently. One example is 5 different make changes to same data entry actions in a single workflow series, with another 15 actions for creating temporary values, deleting temporary values and then creating non temporary values for creation of a blog article.
I’d recommend trying your hand at asking an LLM for ideas on how to build certain features optimally for WUs as not all features/functions in your Bubble app will need to use real code hosted on a 3rd party service provider. Also, check out some forum posts on topic as well. Bubble is so much more fun to build with the more you know about how to build on Bubble. Don’t just rely on AI.
to Boston85719 : First of all, thank you for taking the time to comment. I am entirely self-taught when it comes to programming; although I’ve developed five or six highly specialized professional applications over the last 40 years—some of which saw a fair amount of success—I never underwent formal training as a programmer or analyst, so I really value feedback and advice.
Regarding the structure: for me, the “client” is the subscribing restaurant. They have a subscription to the HACCP (hygiene) module and/or the order-taking module. For the order-taking module, they generally need at least three devices—ideally more—running continuously in real-time throughout the three- or four-hour service period. This includes at least one device for taking orders at the table (though there can be as many as desired) and at least one tablet in the kitchen. Orders appear on the left side of the screen in FIFO order; once the cook confirms an item, it moves to the right side of the screen, ready for pickup. The whole system operates in real-time. A server collects the prepared dishes and confirms them on the screen (ideally using a tablet dedicated to the kitchen-to-dining-room pass), and the same process applies to drinks at the bar. Customers have a QR code at their table to view the menu in their preferred language.
Naturally, generating the sales receipt requires retrieving data from the active table.
That’s the setup. As for redundant actions (and conditions), we are currently rooting them out… When I say “we,” I mean me, BuildPrint, and GPT.
Thanks for reading, and I’ve taken note of your comments.