Hurtle, or How I Ruined Wordle

what is wordle?

If you've been on Twitter and seen green squares in the last few months, you're most likely familiar with Wordle, the hit word game based off of Mastermind. For those who are unfamiliar, a new five-letter word comes out each day, and users have six chances to guess it correctly.

Throughout the Wordle craze, a number of creators on Twitter, TikTok, and other social media have posted videos involving the solution list...with the correct order. This led to two or three of my Wordles being ruined before even approaching the day where the word would be in use. So why should I be alone in this experience?

the premise

Shortly after going through this, I posted a joke to Twitter about creating a service that sends a daily text message to your enemies with the Wordle solution. However, I didn't at all expect people to consider it a worthwhile idea, and after a decent response it was time to embark on this silly journey.

Upon starting the project, I discovered there were some problems with this initial idea:

  1. a daily message to all users would require a cron job,
  2. if (and when) a user blocked the number it was sent from, it would be a pointless waste of money to send the message,
  3. and at no point could I be sure of the current timezone of the person receiving the message.

After sitting on those considerations, refactoring the application idea seemed like the most reasonable path. I targeted a simpler goal—make a service where users can send the solution to a phone number once a day per number.

reworking the implementation

With the planning taken care of, it was time to approach the stack and building out the project. As a React dev, it's incredibly tempting to slap it onto all of my new projects as a competent front-end, but for the sake of this application, it seemed like a bit overkill. After a little research, I settled on the following stack:

  • HTML / CSS / JS (providing a rudimentary front-end using the fetch API)
  • Twilio (sending SMS messages with the Wordle solution)
  • Redis (saving phone numbers to prevent spam)
  • Express (serving the front-end and connecting to Redis and Twilio)
  • Heroku (deploying and serving the application)

an icarus moment...

When designing the application, my one fear was that people would use it on my partner and me as the ultimate dose of irony. So, in writing the application, I added a blocklist to let the user know they had failed in a gentle, kind way: "Nice try, bozo", via browser alert.

"Nice try, bozo"

Unfortunately, creating such a stink about entering my phone number caused someone to actually try to reverse engineer the site to find my phone number. As always, the low tech method proved correct, as they sent it to their phone number, then forwarded me a message from an unknown number. I had already been spoiled for that day's Wordle, so it wasn't the worst solution in the world.

...and a daedalus moment

After this brief debacle, it seemed best to conceal the blocklist within the Redis functionality: if a user attempted to send something to the blocked number, it would tell them that a hint was already sent to that number. It turns out that making jokes does not always mean optimal development.

what i learned!

This project reminded me that an app doesn't need to use a front-end framework to work well, and they can often step in your way. In addition, working through Redis and Twilio for this project proved to be less complicated than I first imagined—and to that, I have the comprehensive Redis and Twilio documentation to thank.

If you're interested in using it, you can find Hurtle here. Thanks for reading!