How I Plan To Build a Dynamic Text Messaging Application with Twilio's SMS API - Part 1

Abdul Hersi

Feb 7, 2023 • 5 min read

I don't know about the rest of you, but I've always been super fascinated with businesses that primarily use text messaging as a way to communicate with their customers. Maybe it's because text messages can at times feel a lot more personal, especially in a day and age where push notifications seem to flood our phones with an excessive amount of reminders. It's sort of ironic, especially since the "text message" is a relatively older method of interaction one can have with their customer. Almost makes me feel nostalgic, where a text message can be sent without an app install, or permission for notifications. So with that being said, time to tickle my fancy(not sure if I'm using this correctly), and find a reason to build something that uses text messaging as a service!

What we're building

Now that we know what service we want to use, we need a problem or solution to solve. Normally, you would see these text messaging features integrated in an app where it isn't the main focus, which isn't the goal here. I'm going to have this feature be the centrepiece.

As for the problem we are tackling, I like to look at thing's in my life that I can benefit from, and see if it applies to a broader group of people. I don't think the size of my target audience would even matter, since I just want an excuse to build, but in this case there might be people who might actually find this resourceful. There are roughly 2 billion Muslims in the world, one being myself, that are required to pray 5 mandatory prayers a day. These prayers are spread throughout the day, and depend on the location of the sun in relation to where the person currently is. For example, someone in London might be have an evening prayer at 5pm, but that same evening prayer can be 6pm in Detroit. I plan to build an application that sends out text message reminders to users a few minutes before prayer time, for all of these 5 mandatory prayers. This makes for an interesting challenge to tackle, and I will get to that in a bit.

Approach

There are a few things that need to get done here, so let's get right to it. We need to send out text messages to users 5 times a day, and we'll be able to do that using Twilio's SMS API to send the messages. The next thing we have to do is find out when to send out these text messages, and these depend on the prayer times for each specific user, since they can be living in different cities. I managed to find an accurate API(aladhan) that would return prayer times in JSON format given I provide the city and country, so that works perfect! I'll also need a website, perhaps something like a landing page that would just collect users phone numbers, along with the country and city they are in. I'll definitely need some sort of database to store these users, I was thinking using Firebase or Firestore, the former seems like it makes more sense, but the latter seems like it might be fun! I almost forgot, I'm going to opt not to host this application on a server in my house, despite how fun that sounds, and I'll probably just deploy it on Heroku. I could be missing a thing or two, but this is just initial thoughts, so nothing is set in stone!

Ok, now that we have all of important things taken care of, let's talk about where things get tricky. How would the sequence of events occur with this application? Will I need to run this application multiple times a day? Will I need to run it 5 times a day, as in before a potential prayer time? But what if I have users that span over 100's of cities? That wouldn't seem logical because they can each have a different time for prayer. Prayer times are dynamic, and change day after day, and I'll need to be constantly updated on those times to know when to send out messages. I have a couple of approaches off the top of my head, and I'll try to be make it quick and to the point:

1- Heroku has a scheduler, much like a cron job, that allows to be run my app at different times of the day. So the idea would be to run the application, see if there is a prayer that will start within let's say a 10 minute window, for any user that is, then send out the message for said user. Otherwise, wait for the next time the application is scheduled to run. This might require me to run my application literally every 10 min. Might sound kind of excessive, but theoretically speaking it should work.

2- After some digging, I found Twilio has a message scheduling feature. This means you could schedule messages as far as 7 days in advance. So my idea is to run this application once per day, let's say at 12am GST, and schedule 5 messages(5 prayers) for each user to be sent for the following day, 10 min before each prayer. Then do the same thing everyday. In order to do that however, I'll have to get all my necessary data. I'll query my database to get all the different cities my users live in, then I'll use those cities with the API that gives me prayer times for each city. Once I have that, I will create a temporary file, and store that information in there. I'm thinking it'll look something like the following:

{
"Vancouver": 
{
	"Prayer1": 04:53,
    	"Prayer2": 12:23,...
    	"Prayer5": 21:33
},
"Boston":
{
	"Prayer1": 05:23,
    	"Prayer2": 11:11,...
    	"Prayer5": 22:46
}

Once that's created, I'll use the Twilio message scheduler API to send out messages for each user 10 min before each prayer time.

Ok there it is, two different approaches, all thought through, but not really tested or attempted. If its not obvious by how much more detail I put in to each approach, I'll be going with approach number 2. I'll feel like the message scheduler is way more logical, and would save me some unnecessary database reads, which is always good practice. So lets do a brief overview of tooling and architecture. I don't need any backend frameworks, there won't be any routing happening. So a python script or two for the business logic, a couple of API's, one to send out messages, one to get prayer times, Firebase for database storage, Heroku for hosting, and probably some vanilla Javascript and HTML for the front end, or I'll probably just bootstrap it.

Closing Thoughts

Looks like I have an action plan to get things moving. Everything I planned out however is just initial thoughts, and I'm totally open to taking different approaches along the way. If I don't hit any major road bumps, I hope my part 2 for this project will be a link to the complete application, and maybe some source code. Until then, thanks for reading!