Seeking Advice: Building an Interactive SMS Service

Hope everyone and their families/friends are doing well,

I have a personal project that I have been thinking of building in Rust and would like advice on how to organize it and/or any advice you can throw my way to help me out. I'm a hobbyist and have no formal programming training.

The Project

I would like to build an interactive SMS service to help remind speakers that are scheduled to give talks.

Objectives

  • When a speaker is added to the database a SMS message is sent out to said speaker asking if they will accept or deny the assignment
    • The speaker replays to the message with accept or deny
    • The speaker accepts or deny the assignment: SMS is sent to me informing me of their reply.
  • Speakers. which are on the schedule, can use commands to receive more information about their assignments.
    • date - date and time of the assignment
    • zoom - details about the Zoom meeting (ID and passwords)
    • contact - The point of contact they would reach out to in case of an emergency or cancellation
    • help - list of commands
    • etc

Libraries & Services

These are the various crates and services I've been looking at as I prepare to build the project.

  • For the text messaging I would like to use Twilio along with the twilio-rs crate
  • For saving configuration files in the correct locations I'm looking to use the directories crate
    • For configuration files: TOML with Surde
  • For asyinc: Tokio
  • For Database: SQLite with the Diesel ORM
  • For command line parsing clap
  • For server: a VPS

Advice

The main advice I'm looking for is how to organize this project:

The program would have to always be running on the server since it can accept incoming SMS messages from speakers at any time. Also, I would need to be able to add and remove speakers from the database.

I'm thinking that I would have to build it as a daemon and install it on the VPS. Have the daemon check the DB for new entries and send out messages when new speakers are found. Also, it would write to the DB to record the answer the speaker gave, date and time of messages sent, etc.

Then build separate tools for the admin, me, to interacting with the DB, adding new speakers for example.

Some questions running through my mind:

  • Is this a good approach?
  • what would be another way to approach this?
  • What kind of pitfalls I might be getting my self into?
    • The async stuff is giving me a little anxiety :sweat_smile:
  • Are there any potential problems or areas I need to watch out for?
  • If you were to build something like this for a big company, how would you go about it?

If you have any other advice, comments, blog posts, YouTube videos regarding what was mentioned above or not mentioned above, send them my way. I can use all the advice I can get.

Thank you for your time! :love_you_gesture:t4:

2 Likes

That approach should work fine.

The deployment story (spin up VPS, use ~/.config/, etc.) probably isn't what I would do for work because it'll require some manual configuration and make your server a special snowflake, but for your use case it's really not a concern.

If I was building something like this for work, I would probably:

  • Write the SMS stuff as an ephemeral server that can be thrown away whenever
  • Wrap it in a Docker container
  • Store state in a Postgres database
  • Create a separate server for the admin UI and wrap it in a Docker container
  • Use docker-compose to make sure my servers and database containers are spun up and connected automatically - this lets me spin up a dev environment with a simple docker-compose up
  • Use environment variables for configuration - ideally this will just be things like your twilio API key and DB connection stuff
  • Wire up GitHub Actions so that whenever I push a commit to master it will automatically rebuild my containers and deploys to AWS using my docker-compose configuration (I think AWS have docs for this)
    • Depending on the situation, you might choose to only use docker-compose for development and write a bunch of Terraform scripts to deploy it to the cloud in production
    • If you don't need the redundancy, spinning up a VPS and using docker-compose up might also be viable

You'll be fine :slightly_smiling_face:

Rust's async story has become a lot more user-friendly over the last couple years as people have used it in the real world. Plus, you can always ask questions on this forum if you get stuck.

Thank you for the reply @Michael-F-Bryan,

Quick question for ya, or anyone else. I was talking to a buddy of mine and we were commenting that maybe Tokio is overkill for my project. I just need two concurrent threads. One to paying attention to twillo for incoming SMS and the other paying attention to the database for changes. What do you think? Does that sound right?

Sources I've touched on recently for anyone interested:

I wouldn't call it "overkill". For something like this you will naturally want to write asynchronous code, and the easiest way to do that is with tokio because that's what most async libraries use.

1 Like

You were right. I've been working through the Tokio tutorial and it's not as intimidating as I thought it would be. The Creating a Chat Server with async Rust and Tokio - YouTube has also helped a lot.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.