In my app, there are 25 different situations that warrant notifying the user.
I send an email (because I want them to know right away) as well as creating an in-app notification (because it allows me to show them a nice little history of all past things that happened).
The issue is, I’m currently looking for ways to speed up my super-slow app, and each notification+email combo takes a good 4-5 seconds to run, so my question to you is:
How do you notify your users about important things? Do you send an email as well as creating an in-app notification or do you do it differently?
We run actions like sending emails in the API. As such, they run in the background and don’t hold up workflows from running/completing.
We’ve also found that this is a nice separation of logic since users can often trigger the same emails being sent from multiple places in our app, and having this in the API enables us to have a single version of the email that’s triggered to be sent from different pages within our app without having to duplicate the logic and email copy.
Sort of what @sridharan.s was getting at, I don’t quite get the comment on time-to-send.
Very little of this HAS to happen live-on-page. Let’s take the example of an appointment/booking tool: You’ve got a looker who is turning into a booker and is obviously viewing the app (they are making a booking).
But when they click that “Book It” button, you can choose whether to execute all the notification stuff right inside the page (and make booker wait while all that completes), or just fire off a “scheduled” “API” workflow (scheduled for Current Date/Time — aka “right now”) and let the user get on with things.
(It’s also probably smart to do that as “what if the user’s session craps out for some random reason?” — fire off the “let’s book it stuff” immediately so it doesn’t get lost in a disconnection disaster would be a good thing to do.)
When building and testing, leaving that stuff in the page is helpful, but the next optimization step (once you’re confident in your workflow) would seem to be to move it to an asynchronous background type of task. (I’ve got lots of stuff like that to do…)
Thanks very much @sridharan.s and @keith for your answers. But if it’s just 2 actions, is it much faster to do that via the API? I figured the API was better for a longer series of actions.
Other notes:
-Each of the notification+emails is only called from 1 place in the app, so there’s no duplication of actions to maintain across the app.
-The data fields used are mostly different for notifications vs emails, so there’s not much duplication of data across the 2 actions, other than the recipients.
Simple Answer
Based on your original message, I got the impression those 2 actions were taking an addition 4-5 seconds total. If so, then moving them to the API would help a lot. If these are just 2 quick actions that take a 0.1 seconds each, then moving them probably isn’t worth the trouble.
Complex Answer
Emails definitely don’t need to go into the API and if you’re sending a simple email there’s probably not much benefit to it. However, if you start segmenting users and sending different emails to different segments (so it’s more workflows) or using lots of searches to lookup values in the email, then it’s nice to have that in the API. More than anything, we run complicated emails (and other workflows for that matter) in the API because if we need to set them up on another page, it’s nice not to have to re-code the logic and keep future changes in sync. So, moving emails to the API is useful for complex apps, and also typically not worth the complexity for simple apps.
Note to self for future reference (hopefully this is helpful to someone else):
The big problem with using the API for sending emails is that, if you want your email to have more than 1 paragraph, it seems you can’t send the email body over to the api endpoint (you can’t include line breaks), which means every different type of email you want to send (i.e. when the body will be different) needs its own action. That, coupled with the fact that debugging is harder and setting up the thing is generally more complex, made it a no-go for me. It may be that the saving those couple of seconds is worth it for some people, but for me, keeping it on the page made more sense.
Update: Actually, I did end up going to the API - I just send every email paragraph separately to the endpoint. If some of the emails have 5 paragraphs and others have 1, it still works because you just make the 5 paragraph endpoints optional.
