Wanted to share a new resource that I hope you find helpful.
We at AirDev believe that Bubble will create a huge number of developers who haven’t necessarily built software before. As a result, we spend a lot of time thinking on how to train them in the best practices of building, which is especially important given how flexible Bubble is. As anyone who’s Bubbled extensively knows, there is a big gap between just building something on Bubble and building it well, using best design, performance, scalability, and security practices.
Thus, we attempt to create resources that help Bubblers not just create applications but create good applications. Below is a link to a document that details our thinking on the best ways to structure the Bubble database, which serves as the foundation of each application and should be the first step completed on any build:
I would love to hear people’s feedback - things that you disagree with, things you would add, etc. I would hope for this to become a valuable resource for those looking to build their application in an optimal way.
Nice document. I think adding more examples with screenshots would be helpful.
I think a section discussing how to setup, and use, “core” tables/data types to make configuration/management easier could be useful – this type of approach could also allow you to create “admin” pages on your app so users could update the app’s content without having access to the Bubble editor.
For instance, I always create a “core menu” table to hold values for all menus I use throughout my app. I then use repeating groups (RG) to display the values. Typically I set a State with the values on page load so the user does not wait for the RG to load when they display the menu in Group Focus elements.
Having an Active field allows me to limit which menu items show.
Having an Order field allows me to change the order of the menu items.
Having a Numerical Value field, that I use in workflow, makes it easier to change a menu item’s Label or Value without having to update workflow.
Other fields could be added based on your app. For example, “Module” in the below screenshot which is used to reference different pages/parts of my app.
@Kfawcett thanks for the feedback! I definitely agree that for anything where frequent updates are needed, storing it in the database is a great practice because it allows users to be able to update the application without knowing Bubble. We do this for our entire homepage in the Canvas template, so that users can update content on it themselves and without a deploy.
We don’t actually do it for most menu items because we find that most menu items don’t change often enough to justify it and, when they do change, they often require additions/changes to the app itself anyway, such as a new group that shows up when a new option is clicked. However, I could definitely see a use case for making some menus be database-driven, such as those where the functionality behind the options doesn’t frequently change but the option order/labels/visibility does.
