Backend variables?

Need help
1

georgecollier, you’re the expert can you give me a one line answer to the following? and I’ll buy you a beer/coffee if you have a link? (or anybody else):-

Doing multiple searches of Subscribers on the backend is inefficient. I want one search and to use that search throughout my backend workflow like custom states/variables for backend. What is the best way to do this?-

Use the app connector, pass the search from front end to backend using parameter (do the search on the parameter)
Use custom events for parameters
Use plugins
Any other way? What’s the most performant, WU friendly option?

Thanks, spending far too much time trying to figure this out.

2

What you describe sound more like a case for schedule API workflow on a list.

What is your end goal, what do you want to do with the result of the search?

3

I am trying to add a subscriber to my newsletter. Two inputs (first name and email). When a user presses the subscribe button I want to send them a verification code and create them as a subscriber but the field (verified) is no until they’ve confirmed via email.

Before this happens I need to check they’ve not tried this more than 3 times in x hours, and that it doesn’t already exist. If it exists but not verified show x message, if it exists and is verified don’t let it happen and show ‘already subscribed’ message.

When they click the email it redirects them, on page load or do when true, pull the parameter (code) and (uniqueID) from the URL and run the app connector (do a search on the app connector parameter to grab that specific subscriber)

On the backend make a change to that parameter (subscriber) to verified = yes, then send the confirmation email, return data (to use custom state messages on front end) i.e You’ve subscribed! or if it fails “Try again”.

Basically:-

The goal is to create a newsletter subscription system where users submit their first name and email via a form, triggering a check to ensure the email isn’t already subscribed (displaying “Already subscribed” if verified, or a verification prompt if not) and hasn’t exceeded three attempts in a specified time frame. Upon valid submission, a subscriber record is created with verified = no, and a verification code is sent via email with a link containing code and uniqueID parameters. When clicked, the link redirects to a page that extracts these parameters, updates the subscriber’s record to verified = yes using an app connector, sends a confirmation email, and displays a frontend message: “You’ve subscribed!” for success or “Try again” for failure.

4

Because this is stored in another app?

I don’t see any reason for using backend WF for you case. This will be done with simple Do a search for in front end when user go back to your link using Get data from URL. One DB “newsletter” with a field for verified and attempt. You could always use two DB one for request and one for newsletter if you prefer.

If you care about privacy rules, you could use app connector or API connector (my choise in this case go to API connector). Basically just to validate that the code is valid and update the subscriber (you don’t need to send both unique ID and code.). According to the result of the validation, you can return data from API saying a message like “sucess”, “expired”, “invalid code”, “Too many attempts” and display the message in front end.

5

It’s truly extraordinary that Bubble doesn’t have any proper way to work with variables inside backend WFs…

The best way (the fastest and most WU efficient) to do this is by using Custom events as variables (assuming you can’t use the WF parameters themselves - which you sometimes can, depending on the use-case).

Any plugins you use for this can add significant WF cost, and slow things down a lot.

That said, for you particular use case I’m not sure you need to store a list as a variable… there are probably simpler ways of doing it, as described already in this thread.

2 Likes
6

Thank you @Jici and @adamhholmes.

I’ve spent so long on here that I often overcomplicate the simple things. I’ve just managed to do it all in 30 minutes without the backend at all. :sweat_smile:

I was under the impression that the front-end workflows cannot search dataType data in Only When conditions because of Privacy Rules. I now believe that they can as front-end workflows are still server side, you just can’t show that data outside of the front-end workflow unless Privacy Rules permit.

I know, it’s madness. Using ‘run APP/API connector’ and passing parameters from the front-end was the only way I knew of doing it but then you’re running the search on the front-end. Custom events is the only way I know to do it on the backend (I didn’t know this until I read your post on this forum from March 2024 thank you for that @adamhholmes!

1 Like
7

Nah, I was right. You literally cannot do a search on a front end workflow and use that data (like do a search for subscribers (constraint: email = this input’s email):count on the front-end without leaking your email in privacy rules.

Would love to be corrected if I’m wrong but you have to do this backend? :sweat_smile:

8

If the subscriber datatype is ‘not findable in searches’ for a particular User then a search won’t find it, so the count will always be 0.

If it can be found in searches, then it will be found (regardless of what fields are accessible via privacy rules).

So you could permit it to be found in searches, but restrict all fields from being accessible, and that will give the correct count, whilst keeping all field values protected.

but it’s more secure to not allow it to be found in searches at all - in which case a backend WF can be used to establish the count.

2 Likes
9

Ah that makes more sense.

Is there much a hacker or competent person could do with enabling the verified (yes/no) field and unique ID of the subscriber in Privacy Rules?

Also if you only ever do an Only when (Do the search here) in the front-end workflows, is it ever accessible via the DOM to hackers or ONLY if you save it in custom states or on page searches (RG, text elements etc)

I don’t even think I can pass the search in a parameter as the search is done on the front end of the App connector (if I restrict all access to it) so literally custom events is the only solution if you want to search for subscribers that match that email and utilise that search multiple times across your workflow, correct @adamhholmes?

10

Hey @ash8 , what you need to do here is to create a backend workflow with a ‘return data from API’ action - this takes in the first name / email → then run your required searches, → and then return the information you need (could be yes/no, subscribed, etc.)

You can do all this with the ‘ignore privacy rules’ checkbox selected.

You would then call this API from your App’s API Connector (recommended) or APP connector. This will allow you to use this information in a normal workflow on the front end.

This is a very common requirement to verifying data that should never be visible to users via privacy rules on the front-end (e.g. for logged out users, verification codes. etc.)

Good luck!

2 Likes
11

Thanks Djack, that’s exactly what I did originally but felt like it was overkill and may be able to move it to the front to make it simpler. I can’t without leaking data. To anybody else reading this:

Privacy rules affect both backend and front end workflows. In the backend you have the option to bypass those rules but the front end workflows are affected if you’re doing searches or finding things that are blocked by privacy rules so any sensitive data should always be done in the backend.

The app connector parameters are front end so searches done here to pass to the backend won’t show if privacy rules restrict. So your searches must be done on the backend. If you need to do several of the same searches throughout your workflow use @adamhholmes’s suggestion of custom events with parameters on the backend, it’s literally the only viable option at the moment to my knowledge.

Thank you to @Jici , @adamhholmes and @DjackLowCode.

12

The search can be done on client side if you allow the search item. Data stay private and external user cannot modify it.

There’s some option to workaround and keep it in front end, but I do not recommend them and you will probably not save on WU.

13

No problem @ash8 - once you get used to the process you can set these up in a minute or two.

You will definitely come across the need to do this again for whatever privacy related workflow at some point though!

1 Like
14

@DjackLowCode , I’d love to be able to do these in a minute or two. Thanks :slight_smile:

This is incorrect:-

Just for anybody learning too, backend custom events do not bypass privacy rules and cannot do so. There’s no option to bypass privacy on them and they do not inherit the “bypass privacy” of the backend workflow that they’re in.

See

From my understanding, if go into Privacy Rules and check ‘Can be found in searches’ but only ever do the searches in the backend using backend custom events, it’s completely secure. Would love people that actually know about this to chime in and confirm or correct me though.

15

I solved my use case and just for anybody else that’s getting a brain aneusrym over this stuff going bald years earlier than planned:-

If you need to reference the same search multiple times on the backend, you can use

custom events to hold parameters but you’d need to check ‘This datatype is searchable’ in privacy rules. It’s secure as you’re still doing the entire search backend.

But I found it a lot better to do this:-

Step 1: Make change to thing (do your search on this) but don’t add any fields or conditions. Leave it blank.

Reference Step 1 anywhere in the workflow.

I believe Make a change to an object but leaving it blank may be faster and more efficient than triggering a custom event to do the same search. Happy to be corrected.

16

The make changes to things trick for search results in a subsequent workflow action has been my go to for half a decade now. Works fine in my opinion.

17

I use custom events to store and return variables.

2 ways
custom events in the backend which are shared across all backend apis
custom events in helper reuseables which I can add to any front end page to do the same logic

a common pattern is create a thing but only if not already created, if exists then return existing

this is easy in a custom event as it silos off the logic
trigger
create conditionally using search for aggregate is 0
return data
in the return you return search for plus result of create : first item

this way the return will either be the existing or the created

you have to use both search plus created because sometimes the search (although it shouldn’t) runs before the created has finished

quite often I’ll use custom events purely to store and process data as well.
ie to merge 3 searches for contacts I’d always use a custom event so that each search is held separately and can then be changed independently without having to rewrite the entire 3 search formula… which bubble loves making us do.

in essence anything that feels a little heavy I just break down into custom events

there is also the added benefit of custom events forcing order of operations - but that also has a downside of slowing down workflows (unless you use schedule custom event then they process alongside each other)

2 Likes
19

Just to add/clarify a few things here…

That’s incorrect.

A Custom Event in a Backend Workflow inherits whatever Privacy Rules settings the Backend Workflow uses.

So if the Backend Workflow is ignoring privacy rules, so too will any custom events triggered within it.

If an item can be ‘found in searches’ then any user that meets that privacy rule can access it. Whether that’s secure or not depends on the privacy rules themselves.

This is a reasonable approach, with 2 caveats…

Firstly, obviously this can only be used for ‘Things’ from the DB. It can’t be used for option sets, or API data, or primitive datatypes, calculated values or data manipulation etc. or anything more complex than defining single (or multiple) database items - so it has very limited use compared to using Custom Events.

And secondly it’s a lot more costly in WU compared with using Custom Events.

Using a Make Changes to a Thing action, although it does NOT incur WU charges for making changes to that thing (I’m almost certain it used to, but it doesn’t seem to now) it DOES incur 0.6 WU as a server action.

Custom events don’t seem to count as running a sever action, nor does a ‘return data’ action within a CE - so using a Custom Event as a variable costs 0 WU.

So, if you’re using 5 ‘Make changes to a thing’ actions in a backend WF to establish some data to work with elsewhere in the WF, you’ll incur WU costs for 5 server actions (that’s 3 WU) plus 5 searches (1.5 WU) and whatever data is returned (e.g. 0.5 WU) so a total WU cost of 5 WU.

Whereas you can use a single Custom Event to define all 5 items and it won’t cost anything to run it, so you only pay for the searches/data (actually, it makes no difference if you run 1 single CE or 5 separate CEs - since they don’t incur any server action charges).

So a total WU cost of 2 WU (5 searches plus the returned data) - less than half the cost of using Make Changes to Thing actions.

There’s no reason to think it’s faster but, as outlined above, it’s definitely more costly in WU - so not more efficient.

3 Likes
20

Did you try this plugin: Store Temp Data (Result of Step X) Plugin | Bubble

21

Yep…

as I said previously, plugins (by their very nature) are more costly in WU and, in many cases a lot slower, than using Custom Events.

2 Likes