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

[akamarski]

Or you can use a proxy service to forward the stripe payload to bubble and inject your own header which you verify in bubble

[boston85719]

@randomanon

George hard carrying the Bubble community once again. Stripe is one of the most annoying things to get right and takes weeks for a first-time builder, so this will speed things up a lot for them.

@randomanon

This is well known on these forums, not sure what you mean by “nobody else has mentioned.” The problem is Bubble messes up the raw payload so you need to use plugin to parse it.

Oh, sorry Rando, I am focusing on this thread when I comment about ‘nobody else has mentioned’, so hopefully that helps clear up your confusion on what I mean. My comments here are about this thread and this boilerplate stripe integration, Not the Bubble forum at large.

@randomanon

Also widely recommended…

But not used in this boilerplate, nor mentioned in this thread. Why didn’t you mention it if it is ‘widely recommended’ and a good practice as an extra security measure when you saw that George did not include it in his Stripe webhooks?

@randomanon

“Secondary control only” seems like the parrot is contradicting itself.

No it is not, because of course you fail to comprehend that the entire statement should be taken together and not just taking out of context small sentences. The parrot also said ‘naive spoofing of an HTTPS webhook is GENERALLY not possible’. Why do you fail to read words like generally or possible or probable? They have meanings and should be understood. That fact that it generally is not possible, does actually mean, in fact, it is possible, which is why it says to use the allow list as secondary control.

@randomanon are you the new strawman? Backend workflows: In what situations do you allow to run without authentication? - #19 by randomanon

[randomanon]

@boston85719

That fact that it generally is not possible, does actually mean, in fact, it is possible, which is why it says to use the allow list as secondary control.

“Secondary control only” means relying on it as a primary control is unsafe. Which would contradict “generally not possible” depending on how you look at the use of the word “generally.”

[georgecollier]

@boston85719

But not used in this boilerplate, nor mentioned in this thread. Why didn’t you mention it if it is ‘widely recommended’ and a good practice as an extra security measure when you saw that George did not include it in his Stripe webhooks?

You can add IP restrictions if you’d like. There’s also nothing inherently insecure about the current implementation. The worst outcome is a WU-DoS, and any motivated attacker would have dozens of ways to do that to a Bubble app.

I’m not (and never have been) saying you shouldn’t add IP restrictions to a Stripe webhook. Just that the implementation in this boilerplate is sufficient.

@login

Lock main element groups by default.

True, I’ve never really used that feature but this would be a good use case for it. I imagine it would confuse me the first time when I can’t move something about and I’d bang my head against the wall asking why

[rico.trevisan]

Good stuff, thanks for sharing.

What’s your guideline to adding things to the Global reusable?

I’m currently passing a bunch of messages from reusable to reusable using run Javascript; I’m wondering if there’s a more maintainable way to do that with the Global reusable.

[georgecollier]

@rico.trevisan

What’s your guideline to adding things to the Global reusable?

Stuff you use in multiple places which are inconvenient or inefficient to reach via an expression or pieces of front-end custom logic that need to be used in multiple places.

If your global reusable simply has a dynamic expression as its default and you don’t override it where you place it on the page, all the expressions will be identical, you’ll only be WU charged once, and you’ll have the same data accessible everywhere.

[rico.trevisan]

@georgecollier

If your global reusable simply has a dynamic expression as its default and you don’t override it where you place it on the page, all the expressions will be identical, you’ll only be WU charged once, and you’ll have the same data accessible everywhere

Interesting. So the expressions will follow this logic but the HTML will render multiple times.

So I could use that OOP idea (Bringing Object-Oriented Programing (OOP) to Bubble | by Guillaume Maison | Medium), create a reusable for each element that needs creating and then sprinkle that wherever I need in the system.

---

Which leads me to think (dangerous, I know):

• Bubble feels snappier when you use CRUD actions in the frontend (optimistic updates? No cold-start time when these functions run in the frontend?)
• I can have these “Object Reusables” that have those complex workflows built inside of it.
• so I can move all these complex and slow backend workflows to the frontend.
• … I would need to re-read your guide on frontend workflow security again.

How bad of an idea is this?

[georgecollier]

@rico.trevisan

• so I can move all these complex and slow backend workflows to the frontend.

@rico.trevisan

How bad of an idea is this?

Complex and slow logic should be in the backend

[kuntaykunt]

If you can help , I want and need to understand this Global logic.

Global is a reusable element that can be put whatever we want on application page to use dynamic values.

Design
inOnPageRoot - yes/no - (First question , it is always on the page why we have this option ? is it because i can put it in a group to use the data for the group ?)
Current View - …..URL..**v=“data”

HTML element** : CSS script is in option set , this can be written , or hard coded in to html i guess (Please correct me if i am wrong). All effort is to make it invisible and not blocking any content on screen.

Workflows

• lastLogin date is changed on page load with a condition.
• Custom Event to handle Error viewing - This is used for auth errors
• Unhandled Error viewing / There are 3 permission rule to manage user , subscription and account here

How to Use

First : Put on a desired place and create workflows to manage permission.
Second : On the desired page , the auth. data is there (yes/no) to use to block a group or a menu or a button and you also got the notification.

When a development needed for the application , you can manage permission by doing it or adding it in Global reusable , you can use the auth./perm. data all over the page to finish the design quickly without calling any workflow and extra conditional steps.

Normally , i could create permission table and make desired roles as yes/no value for the users. When i design the page , build logic on ”page is loaded“ workflow for the top perm. control like “Current User’s Permission’s Subscription is yes”. Also for the group based permissions , make some groups not visible to user who has “no” permission to see like “Current User’s Permission’s Payment is yes”. This could get the data from server safely for the user and at first place data should not be downloaded on server side for the groups are not visible… (I guess)

I want to learn because i want the sidebar and menus , some groups act dynamically with the value of Global value , easily.

[georgecollier]

@kuntaykunt

inOnPageRoot - yes/no - (First question , it is always on the page why we have this option ? is it because i can put it in a group to use the data for the group ?)

This just means that it’s in the top level of a page. There should only be one global reusable element where this is set to yes, as it might be used to handle things like page loaded actions. You don’t want that to happen once for each global reusable element on this page - only once in the root element that exists directly on the page.

@kuntaykunt

Current View - …..URL..**v=“data”

This means we don’t need to use Get X from page URL everywhere with magic values/hard coded texts. It makes it easier to construct navigation in a maintainable way. You can see this on the visibility conditions on /dashboard.

The use case for the permissions custom events is to prevent client side group data values / states etc being manipulated by the user. It verifies inside the workflow logic that this is a thing the user has permission to modify, and they haven’t just changed the data inside the group to a thing they can read but shouldn’t be able to modify.

[kuntaykunt]

I see , this is a new approach for me. I was looking for a benefit , design shortcut first so i missed the point.

Data privacy , conditions and visibility rules are there to make the application secure , however this is one step ahead for the data security. I know this now : if a user tweak state on client side then they can manipulate the data or viewing options according to design flaws of an application , which leads us to design a solution(here Global) to stop them on client side.

Thank you @georgecollier for the insight and also sharing how it should be. I also have learnt a lot when people shared application statics produced with buildprint , like how many APIs and workflows and longest expressions. Many many thanks.

[kuntaykunt]

Another one ,

Why did you use “FloatingGroup hidden variables” in reusable elements , rather than using the “Custom States” in the reusable element’s page ?

Both can be used in root page and updates with the relevant values.

—

Edit:
Let me ask this way , there are three places that we can use to pass variables. You are not using custom states in the application deliberately as i see , is it about security ?

[georgecollier]

@kuntaykunt

FloatingGroup hidden variables” in reusable elements , rather than using the “Custom States” in the reusable element’s page ?

@georgecollier

Custom states and group variables

Against custom states

We do not recommend using custom states at all. There are a few reasons for this:

• They are functionally inferior to group variables, as they cannot be set dynamically in an elegant way
• They are not as visible as group variables in the editor

In almost all cases, anything a custom state can do, a hidden variable can do better. One notable exception is passing data between reusables.

In defence of group variables

A group variable refers to making a group or repeating group have a data source. That is not to display anything, but is to store a dynamic variable that you can later reference. For example, if you reference an ‘Invoice’ in multiple places on the page, it makes sense that all references to said invoice use the group variable.

We recommend naming group variables as var - [name]. This makes them easily searchable and distinct in your scan flow. It doesn’t necessarily have to be var exactly - VAR might look cleaner to you, and that’s okay. It should, however, be short end easily searchable. var is convenient to type with one hand on the keyboard.

• Group variables are highly visible and can be dynamically set
• Group variables can be placed globally (e.g. in a hidden floating group), or locally (next to where they are used)

Storing hidden variables in a popup or floating group is functionally identical with the caveat that plugin elements generally do not load in a popup, so it would be advantageous to use a floating group. That said, I’m normally in the habit of using a popup which is fine for most use cases, so you do you.

Let’s unpack what I mean by placing a group variable globally or locally.

Suppose we have an invoice page, where we display the invoice’s line items, and also some customer details. The customer details are collapsed by default.

In a popup, we would have a hidden variable var - Invoice. This references the invoice we’re displaying, and would often come from a reusable element data source or property. Also in the popup, we would have var - Line Items which is a repeating group that stores the line items to display. The search constraint would be Do a search for Line Items where Invoice = var - Invoice’s Invoice.

These are global variables that dictate the entirety of what the user sees, hence they’re positioned in a hidden popup where they can all be viewed and managed together.

Now, let’s consider the case where we want to monitor the expanded state of the customer details. I may have a hidden variable right next to the customer details card, called var - customer details expanded. Why? Locating the hidden variable geographically close to where it is used/updated can assist understanding its functionality. You can judge which location for the particular hidden variable is right for you.

How To Build A Good Bubble App (Not Quite Unicorns Style Guide & Development Philosophy)

Not Quite Unicorns Style Guide & Development Philosophy This guide details an approach to building Bubble apps followed by Not Quite Unicorns, the youngest Gold tier Bubble agency. A version of this exists on a Google doc which you may find more readable: Not Quite Unicorns Style Guide & Development Philosophy - Google Docs This guide may be updated, but the forum restricts edits after a while, so you can use the Google Doc as the source of truth. Background Not Quite Unicorns (NQU) …

[boston85719]

Group var has a tendency to be overused. Just did a training session to help optimize WUs and app speed. Found an overuse of group var as core source of issue. Were placed inside each reusable that might need value, but value is in URL parameter. So removed all group var and replaced with single Get Data from URL.

Also, if var groups are dependent on some other value, users often overlook conditionally loading the data source, with condition based on existence of dependent value.

In that situation we didn’t need custom states at all, just the Get Data URL and property on reusable to pass through to nested reusable.

Also, definitely best practice is in floating group instead of popup as George mentioned.

[georgecollier]

@boston85719

definitely best practice is in floating group instead of popup as George mentioned.

I got that from you