Best Way to Add Email Notification? [Speed of App is Top Priority]

If app speed is the top priority, what’s the best way to add an email notification when new thing is created?

NOTE: Speed of email is not the priority. I’m concerned with the time it takes to run the workflow (aka App Speed).

The Situation:
Picture something like home inspection software. There’s a bunch of home inspectors using a bubble app on mobile in the basement of people’s homes. It works great, even if cell phone service is poor. But now the office wants an email notification each time an inspector creates a new inspection form.

Sweet, we know how to solve this. We’ll just add a step in the Workflow to trigger an email after new thing is created.

Unfortunately, this causes problems.

As you read the problems below, keep in mind this app is used when cell phone service is not always the best. And these inspectors need to create a new form for each appliance and room in the house (which is why speed is such a priority).

After adding email, here are the problems:

Problem 1: Reliability. 1 of 12 times the workflow will error out. This didn’t happen before.

Problem 2: Speed It takes anywhere from 6 to 50 times longer to run this workflow when email is added.

Here’s a video of three different scenarios I tired(time of workflow at bottom left of each):

  • Green: (.384 Seconds) How fast the app runs before adding email to the WF.
  • Blue: (2.104 Seconds) Triggering a Backend WF that sends the email.
  • Red: (2.73 Seconds) Triggering a Frontend WF that sends and email.

Is there a fourth way to run this? Maybe a way that doesn’t slow my app?

Here’s all three scenarios. gif2speed

UPDATE: Thanks @ed727 for the solution. Here’s more supporting info for the solution.

Would be faster to send an email with google app script probably. That would also remove stress from your bubble apps shared resources!

It would be a quick and simple API call. I think that this would be completed client side as long as you don’t need to do any data calls to send out the email.

I have roughly outlined how to do that here

1 Like

Thanks! I’m unfamiliar google app scripts. My current email setup is through postmark, which is a transactional email API.

I tested both client side API and Backend Workflow API. Backend WF is slightly faster than client side, but they are still 5x - 60x slower than the workflow without an email. And also less reliable.

Do you think google app scripts Api would be faster than another email API?

Side note: I don’t care how long the email takes to send/ receive. I’m trying to decrease time of workflow to complete.

That’s what I think would save you time. It should only take as long as it would to connect and send the data to finish the workflow. The rest of the tasks are removed from your server and therefore no longer an issue

1 Like

Since I’m sending it to the backend workflow - I don’t think it will matter which email service I use. I tried other email services (including bubble native) and still had the same results. The delay is the time it takes to trigger any backend WF.

I’ll give your option a whirl to see if it does anything faster. I’ll try anything. Much appreciated.

P.S. - Do you use Thunkable and bubble together? I’ve considered different options with native (BDK bubble plugin, Adalo, Thunkable etc.).

1 Like

Yes
I have used thinkable to wrap a Bubble app. Thunkable gives access to a few services such as push notifications which is what I needed. I do not have access to things like in our payments yet, but following the admin’s in the thunkable forum, it sounds like in app payment is going to be possible for both android and iOS apps very soon on their platform which only makes it a stronger competitor in my opinion.

1 Like

Have you considered having the backend workflow email notification run off a trigger (whenever the new record is created, send the email). That way it’s not touching the client side at all. (I haven’t used triggers yet, but I believe that’s how they are supposed to work).

1 Like

@ed727 I think you’re on to something. I’m not sure what you mean by triggers? Do you mean create a custom event?

Hi, I think it’s this one – you want it all on the backend – Trigger Event - Bubble Docs

OK @ed727 I like how you’re thinking. It seems like trigger events only operate when things are modified. Not off new things.

Example, when users phone number is modified, then we could use a trigger event. I don’t know if you can use trigger events when new user is created.

This is exactly what I would need though.

Hmm… if Bubble won’t trigger a backend workflow off an addition to a database, what if instead you moved the creation of the new record to the backend, and added a step to that backend worfklow to also send a notification email. Theoretically that should be pretty fast.

1 Like

@ed727 this is getting really interesting. I like this.

So here’s what I did before:

[client side] create new thing and schedule back end WF. → [backend wf] send email

So I think you’re saying I should move more of this to the backend. You might be saying this:

[client side] schedule backend WF → [backend WF] create new thing and then send email.

is that correct>?

Interesting that “trigger” vs. “schedule” might save me some time. here’s detail on that.

Yup, move it 100% to the backend. If every time a new record is created you want to send the email, then you can just create 1 backend endpoint that creates the record and sends the email.

I’m by no means a backend expert, but when I had frontend stuff that was moving slow I’ve seen performance improvements moving it to the backend.

1 Like

@ed727 you’ve officially offered a 4th way of doing things. See #4 below . However, it’s still way slower than creating a new thing on the client side without the email. It’s crazy that bubble is so fast with client side “create new thing” WF.

See image below. It’s a fraction of a second vs two seconds. This difference is larger when mobile service is bad. I’m guessing the gap could still get up to 60x slower.

@ed727 your way of thinking might lead to another solution. I just haven’t figured it out yet.

I really appreciate these ideas.

I’m working this. Client side api call to google script to send an email will be quick. I’m halfway there.

2 Likes

That’s really bizarre, and undermines everything I thought about backend workflows leading to performance improvements. I’ll need to do some testing of some of my workflows because I’m curious if I see the same.

You might want to approach Bubble support with this conundrum; they may have some insight into what’s going on.

One thing I do wonder if it has anything to do with the image being processed faster on the front end (maybe because Bubble is doing some compression), but that compression isn’t happening when the image is sent to the backend. Maybe try running it without the image and see what happens?

Putting the creation part aside, sending the email via backend should be a lot faster than front end. I’m going to experiment with that as well to see if I get the same delay. I’m using postmark as well.

1 Like

Hi @brad.h, I’m curious why it matters how long it takes to process the send email workflow (especially as a backend WF), does it stop you from moving on to other functionality in the app? I.e when you click the ‘create thing’ button, if it’s a backend wf does that stop your user from navigating elsewhere or firing off other workflows?

I’m curious as I have a lot of transactional postmark emails as well (mainly backend) and I don’t care if it takes a few extra seconds to send an email in the background as long as my users can still be continuing on with using the app.

1 Like

@ed727 keep in mind. It’s still a bit faster if you move everything to the backend vs everything on the front end. Which is exactly what bubble tells us. My problem is when I add email to the workflow - it slows the WF down by 5x or 60x. And it seems to do this no matter which WF type I add it to.

My situation is with adding email to the WF. It makes it way slower than without email (and less reliable), especially with poor cell phone service.

@equibodyapp good question. Yes. After the WF is complete they get a result, which they may need before moving forward. Also, it’s seem to be less reliable with low cell service, so it may fire an error to them, which looks really bad.