🎉 Better Boilerplate by Not Quite Unicorns - Our take on what a good Bubble app looks like

[georgecollier]

@boston85719

In your experience, would you use the same data in the side bar for the dashboard as for the admin page?

Nope! Which is why the sidebar generates its list of items from the sidebar item option set, so it can be entirely different. And, it’s pretty self documenting / just ‘works’.

You can see from here that if you wanted to use it on admin page, you need to create an Admin page option, then just add the items you want with the Pages including the admin page and the appropriate role. You know it won’t break anything else.

@boston85719

Why do you not use the same page that is dashboard as the admin page?

If the admin page is separate and protected by a server-side redirect, it means I don’t need to add workflow conditions on every single workflow on the page, as Bubble’s security logic will protect them for us.

@boston85719

In your option set for sidebar, why not make it easier to setup the icons and just use font awesome as an attribute

Doing this would 100% be more maintainable, I just hate font awesome

@boston85719

If it has distinct single responsibilities, and is not used in more than one part of the app, it should not be a reusable element.

Most of the time, you don’t know if it’s going to be used in more than one place!

@ankur1

My point is, what if a user gets their subscription ID and keeps repeatedly calling the “stripe-subscription” endpoint, or in some other case? Instead of thinking about so many different use cases, why not just put the restriction? Or you can verify the Stripe signature too.

I mean, they can do so if they want. They won’t be able to do anything, we’d just incur more WU than maybe is necessary (though if a user wants to ‘WU-DDoS’ us there’s plenty of ways to do that). There’s absolutely more layers of security you could add to these webhooks:

• Admin token and Current user’s unique ID contains admin
• IP filter
• Webhook signature check

…many of which I spoke about here: Securing Stripe webhooks without authentication

@ankur1

DB naming convention – sometimes you use camelCase, sometimes you use “Billing Account.” Is there any specific reason behind it?

Please see the docs on this but tldr is primitives are camelCase, data types + option sets are Capitalised Like This!

@ankur1

Why use the DB trigger? Instead, you can just add the condition for a fallback avatar or updating the “full name”-that will save so many workload units.

A name could be updated in a few places e.g when an account is creating in the backend by inviting a user, when the user is updating from their profile, when an admin wants to change a user etc. Full name is just a sync of first + last name and it means we don’t need to think about it at all for the rest of the app’s development. It won’t save ‘so many’ workload, as how often are people really updating their names?

@ankur1

Won’t this condition fail, as you don’t set “isSignedUp” as “no” as the default value, and then “isSignedUp” will be empty?

A yes/no cannot be empty in Bubble, if empty it’s evaluated as no.