I run an agency that only works because we can build things maintainably (meaning that features are easy to revisit and iterate at later on). Here’s what I’ve learned from experience:
Almost all popups should be reusable elements.
URL parameters are generally much easier to work with than URL paths.
Every app needs a ‘Sign Up’ backend workflow that runs when a User is created.
CSS should be stored in an option set with the style and ID as attributes.
A single reusable popup can be used for all confirmations (including deletion) in an app.
Every app should have a Billing Account as a separate data type to store payment related data (e.g., stripe customer ID, subscription data). You’ll thank yourself when your B2C app starts allowing team members.
A global reusable element can be placed anywhere, and its custom events can be used to have reusable workflows across your app.
In the backend, instead of statically defining API tokens in URLs (e.g., ?api_token=XXXXX), have a custom event that returns an admin API token and use that.
Backend custom events are environment variables.
Front-end custom events help you modularise and make sense of madness.
API calls to your own app can use [Website Home URL]api/1.1/wf/your-workflow.
It’s rarely wise to store plan/product data in option sets. Store features in option sets, but limits, pricing, IDs, etc., should be in a data type.
Large workflows with many actions don’t make you look smart - modularise into smaller components.
Never launch without at least basic analytics.
Group variables are generally easier to locate and understand than custom states and can be dynamic.
Add privacy rules first, as soon as you create a data type.
If your data type’s fields have common prefixes (e.g., addressLine1, addressLine2, addressCity), then it strongly implies it should be a separate data type (Address).
Install plugins judiciously, and uninstall them as soon as possible when not being used.
Every API Connector JSON body parameter should not have quotes. All API Connector input expressions should have :format as JSON safe. That guarantees your calls are always JSON safe.
Loading states should almost always be a reusable element.
URL paths are so fiddly because Bubble doesn’t have a very natural way of navigating with them. It doesn’t have a concept of a parent page/path. So, you end up with a lot of hardcoded links in your Go to page actions etc.
Every app is different, but most of our apps have the following options:
SPA View (something that appears in the sidebar)
SPA Tab (a tab that belongs under a view)
SPA Subtab (a subtab that lives under a tab / within it)
These are related (e.g an SPA Tab may have a List of Subtabs, and multiple tabs could belong to multiple views).
You will want to be able to sign up users from multiple places in your app e.g sign up page, admin panel, invite page.
All of those need the same logic, which might include:
creating a billing account
adding them to your email marketing platform
setting up certain fields
sending emails
sending analytics events
By consolidating that into one workflow, you can funnel all kinds of user creation operations through one set of logic so that you don’t repeat yourself (e.g have a parameter ‘isInvited’, and when ‘isInvited’ is yes, send the email which says they’ve been invited, and who by, etc.
Additionally, it’ll speed things up for your users. None of those need to happen immediately, they can wait a few seconds in most cases. So, offload them to the backend, while the user continues merrily towards paying for your product (hopefully).
thanks for the quick answers pretty good points again. do you have any suggestions for end user permissions, managing user roles (for an inventory system e.g.) but user can have different roles in different warehouses etc.
Thank you George for taking the time to post this.
Although where I’m at with my learning of Bubble right now I have no idea what some of this means, I’m sure in time I’ll come back to this and it will all make better sense.
